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PREFACE 


8.1 MANUAL OBJECTIVES AND READER ASSUMPTIONS 


This manual describes the procedures to be followed by the system 
Manager to perform an RSX-11D system generation. Understanding of the 
introductory material in the RSX-l11D User's Guide and a_ general 
knowledge of RSX-11D is a prerequisite for the use of this document. 


9.2 STRUCTURE OF THE DOCUMENT 

Chapters 1, 2, and 3 introduce system generation. Chapter 2 describes 
the process of transferring the system from the distribution medium to 
the system disk. Chapter 3 contains the basic steps that must be 
followed to perform any type of RSX-11D system generation. 


Chapter 4 describes the directives used to define the hardware 
configuration and allocate memory. 


Chapter 5 contains further system generation information. 


Chapters 6 summarizes the procedures available for tailoring 
individual components within the system. 


6.3 ASSOCIATED DOCUMENTATION 
Associated RSX-11D documents are described and their readerships are 


defined in the RSX-11D Documentation Directory, Order Number 
DEC-11-OXUGA-D-D. 
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CHAPTER 1 


OVERVIEW OF SYSTEM GENERATION 


System generation is the process of building a system that is tailored 
to both a particular hardware configuration and the requirements of 
the application programs that execute in the system. An RSX-11D 
system is distributed to the user on one of the following media: 


@ Magnetic tape (7-track or 9-track), 
e RK®@5, RK#6 cartridge disk. 


A magnetic tape distribution is used to form a bootable disk system. 
A disk distribution comes as a bootable disk system. 


Among the system programs provided by RSX-11D is a system generation 
program that executes in two phases to create an expanded or modified 
version of the system. This program is designed to accept 
user-provided definitions of the system to be created. 


System generation is performed in two phases. The first phase can 
execute in a normal production environment without disturbing system 
operation. The second phase must be performed on the target hardware 
configuration. 


System generation normally is performed for one of the following 
reasons: 


l. Creating a system for task development, as described in 
Chapter 2, "Getting on the Air," 


2. Revising a system to reflect an altered physical 
configuration, . 


3. Revising a system to tailor it to its applications in order 
to improve performance. 


The information needed for reasons 2 and 3, above, is described in 
Chapters 3, 4 and 5. 


OVERVIEW OF SYSTEM GENERATION 


1.1 CONCEPTS AND TERMINOLOGY 


RSX-11D is a partitioned multiprogramming system. Partitions are 
named, contiguous blocks of memory, the number of which is’ fixed 
during system generation. All tasks in all partitions can execute in 
parallel. Partitions can be either user-controlled or 
system-controlled. 


A user-controlled partition can accommodate only one task at a time. 
A system-controlled partition can accommodate as many tasks as can fit 
in the defined physical space. All tasks in a system-controlled 
partition can run in parallel. System-controlled partitions can 
schedule tasks on a priority basis or on a time-slice basis. 


An active task is one in main memory that is competing for system 
resources. In a priority-oriented partition, a task can be 
checkpointed to make room for a higher priority task to execute in 
that partition if the first task is designated as checkpointable. 
Likewise, in a time-scheduled partition, a checkpointable task can be 
checkpointed if its time-slice expires. 


Before a task can execute, it must be installed. More than one task 
can be installed to run in a partition. The main purpose of the 
installation procedure is to record disk retrieval pointers in the 
Executive S main memory so that the task can be made ready to execute 
with minimum delay when a request is issued for it. The task can be 
either explicitly installed using the INS command to MCR or implicitly 
installed as a result of a RUN command issued by a nonprivileged user. 
Tasks installed as a result of RUN are removed automatically when the 
task exits. Tasks explicitly installed can be removed using the REM 
command. 


The system task directory (STD) establishes the maximum number of 
tasks that can be installed at one time. Normally the number of 
installed tasks is greater than the number of executing tasks. The 
number of simultaneously installed tasks is limited by the number of 
system task directory entries specified during system generation. The 
number of executing tasks is limited by the number of user-controlled 
partitions plus the number of tasks that can fit into 
system-controlled partitions. The number of STD entries for tasks 
should be greater than the number of available partitions so that a 
maximum number of tasks can execute simultaneously. Installed tasks 
can be removed when no longer needed to free additional STD entries. 


In RSX-11D, some of the dynamic memory requirements are satisfied from 
a pool of nodes. Nodes are variable-size memory blocks that are a 
multiple of 8 words. The size of the node pool is established during 
system generation. 


CHAPTER 2 


GETTING ON THE AIR 


This chapter describes the organization of the media on which RSX-11D 
is distributed and the procedures to be followed in preparing these 
media for the initial system generation. Section 2.3 contains’ the 
instructions for use of the various bootstraps available on the 
PDP-11. Section 2.4 describes how to use the basic system as 
distributed to generate the Terminal Handler task for the desired 
configuration. This must be done before the main system generation 
described in Chapter 3. 


2.1 THE DISTRIBUTION SYSTEM 


RSX-11D systems are distributed on three basic media: magnetic tape 
(7- or 9-track), RK@5 cartridges, and RK#6 cartridges. 


2.1.1 Magnetic Tape Distribution 


The system distribution tape contains a number of bootable system 
images. These are run in turn to create a single-terminal RSX-11D 
system from the files also contained in the system distribution tape. 


2.1.1.1 Procedures for Using the System Distribution Tape 
1. Using the procedures for the particular ROM bootstrap 
described in Section 2.3, boot the system tape into memory. 
The system prints the following on the console. 


RSX-11D V@6.2 SYSTEM DISTRIBUTION TAPE 
SYSTEM DISK? 


2. Respond with the device name to indicate which device is the 
system disk. For example: 


RK@5 for RK#5 system disk 
RP#6 for RP#@6 system disk 


3. Once the name of the system device has been typed, the system 
prints the following message or its equivalent: 


LOAD DISK ON xy@ WRITE ENABLED 
TYPE “CR° WHEN READY 


where xy is the device type. For example, xy is 


DK for RK#5 system disk 
DB for RP#4, RP@5, or RP®@6 system disk 
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DM for RK#6 system disk 
DP for RP@2 or RP#3 system disk 


When the disk is ready, type carriage return, and if the 
can be formatted, the system prints the following: 


FORMAT DISK? 


NOTE 
Formatting a volume destroys all 
information on the disk as does running 
BADBLOCKS (step 6) and initializing 
(step 8). 


Respond with one of the following: 


YES to format the system disk 
NO if disk formatting is not reguired. 


The system then prints the following message: 
RUN “BADBLOCKS °? 


Respond with one of the following: 


disk 


YES to run the BAD BLOCKS utility (see RSX-11D User’s 


Guide) on the system disk 
NO if this operation is not reguired. 


The system then prints the following message: 
INITIALIZE SYSTEM DISK? 
Respond with one of the following: 
YES to initialize the disk 
NO if the disk does not require initialization. 
NOTE 
This question will not be asked if 
either or both of the previous’ two 


replies were YES. Initialization is 
mandatory in these circumstances. 


If initialization is not required then the system continues 


from step 12 onwards. 

if the disk requires initialization, the system types: 
STANDARD VOLUME INITIALIZATION? 

Respond with one of the following: 

YES if standard volume initialization reguired 


NO to make the initialization task prompt for 
initialization parameters. 


the 


See the RSX-11D User’s Guide for a description of the MCR 
command INITIALIZE VOLUME. Standard volume initialization 
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gives the volume a label of RSxXSYS 


With standard volume initialization, if the reply to the 
BADBLOCKS question was YES, the volume will be initialized 
with the /BAD=[AUTO] option, otherwise without. 


12. The system is then created. 


The system prints the command file used during system 
creation on the console. 


During this process, all of the files required on an RSX-11D 
system disk are loaded from the tape and a complete basic 
system is generated on the target disk. If all the replies 
to the three guestions in 4, 6, 8 above were YES, the process 
will take approximately 15 minutes for an RK@#@5 system or 
approximately 38 minutes for an RP@4 system. When finished, 
the system prints the following. 


*** END OF SYSTEM GENERATION PHASE 2 *** 


13. Enter the time and date, dismount the system disk and_ save 
the new system as follows: 


Press CTRL/C to obtain MCR NOTE 

MCR>TIM dd-mmm-yy hh:mm:ss In* this manual, all command 
MCR>DMO SY: lines are terminated by pres- 
MCR>FIX F11ACP sing the RETURN key unless 


MCR>SAV otherwise specified. 


14. The system then responds with a sign-on message giving the 
actual memory size and the version of the RSX-11D Executive 
that is in use. 


All of the system memory is available. If the hardware has 
more than 48K, a message in the following format is printed 
on the terminal. 


SAV -- PARTITION GEN EXPANDED BY nnnn*32 (DEC) WORD BLOCKS 


In addition, if the central processor is a PDP-11/7@0, it has 
been enabled as such, thereby overriding any previous 
specification. 


15. The new system disk is now usable as a base for tailoring the 
desired RSX-11D system. Every time this disk is booted, the 
message in step 14 above is printed. If, however, the system 
is saved again, the size of the expanded partition will be 
recorded and the amount of expansion will not be printed. 


2.1.1.2 Procedures for Using Auxiliary Tapes 


The directory organization of RSX-11D is described in Section 2.2. 
This section describes the procedure for obtaining files from the 
object tapes, which are the other two tapes in the magnetic tape kit. 


The files are written on tape in DOS format. The file interchange 
utility (FLX) is used to obtain files from the tape. The FLX commands 
are described in the RSX-11D Utility Programs Procedures Manual. 
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2.1.2 RK@5 Cartridge Distribution 


The first of the three RK#5 cartridges is a single-user 48K RSX-11D 
system. The other two cartridges contain object files and command 
files for rebuilding system components. All three are Files-1ll 
volumes with a directory organization that is described in Section 
2e2% 


It is advised that all three disks be copied for backup purposes 
before any other use is made of them. Preserve (PRE) is the utility 
to be used for this operation. Refer to the Preserve Manual. 


To use the system disk, it need only be bootstrapped from device @. 
See Section 2.3 for the appropriate bootstrap operation. When the 
disk is booted, the system displays the sign-on message for this 
version of the RSX-11D Executive. All of the system memory is made 
available. If the hardware has more than 48K, a message in the 
following format is printed on the terminal. 


SAV -- PARTITION GEN EXPANDED BY nnnn*32 (DEC) WORD BLOCKS 


In addition, if the central processor is a PDP-11/78, it has been 
enabled as such, thereby overriding any previous specification. 


2.1.3 RK#6 Cartridge Distribution 


The RK@6 distribution cartridge contains a single-user 48K RSX-11D 
system, object files and command files’ for rebuilding system 
components. The directory organization is as described in Section 


202. 


It is advised that the disk be copied for backup purposes before any 
other use is made of it. Disk Save and Compress (DSC) is the utility 
to be used for this operation. Refer to the Disk Save and Compress 
Manual. To use the system disk, it need only be bootstrapped from 
device @. When the disk is booted, the system displays the _ sign-on 
message for this version of the Executive. All of the system memory 
is made available. If the hardware has more than 48K, a message in 
the following format is printed on the terminal. 


SAV -- PARTITION GEN EXPANDED BY nnnn*32(DEC) WORD BLOCKS 


In addition, if the central processor is a PDP-11/79, it has been 
enabled as such, thereby overriding any previous specification. 


2.2 ORGANIZATION OF DIRECTORIES ON THE DISTRIBUTION MEDIA 


Whether the system distribution is on magnetic tape or RKO5 
cartridges, the organization of directories is the same: 


[31ll,n] contain source files, and assembly command files, 
[2ll,n] contain listing files, 
[1lll,n] contain task map listings, 


flijntl; (excluding [11,1]) contain all object files, build 
(overlay description) command files, and command files 
for the librarian, PIP and system generation. 
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2.2.1 System Disk Directories 
An RSX-11D system disk has the directories listed in Table 2-1. 


Table 2-1 
Contents of System Disk 


CONTENTS 


(1314 Executive symbol table 

System macro library 

System resident and relocatable object library 
[1,2] Error message files 


[1,3] Temporary files used and created by the 
Files-1l1 verify utility -- initially empty 


[1,4] Output spooler queue and spooled 
files -- initially empty 


[1,5] Task accounting data files -- initially empty 


[1,6] Error logging data files -- initially empty 


[11,1] All system task images 


[11,17] System generation command files 
Bootstraps 
System,generation phase 2 task 
Executive task image 
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2.2.2 Auxiliary Media Directory Contents 


The auxiliary media contain the directories listed in Table 2-2. 


Table 2-2 
Contents of Auxiliary Media 


CONTENTS 


[11,2] 


{11,4] 
[11,5] 
[11,6] 
(11,7) 
[11,19] 


[11,11] 
[11,12] 
[11,13] 


[11,14] 
[11,15] 
[11,16] 


[11,17] 


[11,29] 


[11,21] 
[11,22] 


[11,23] 
[11,25] 
[11,26] 
[11,27] 
[11,39] 
[11,32] 
[11,41] 
[11,42] 


All modules that compose SYSLIB, SYSRES, and 
the Files-1l1 system 


FLX object modules 

Object modules of PIP, DMP, VFY, ZAP and PAT 
SLP object modules 

Librarian object modules 


MACRO-11 Assembler object modules 


(cross-reference version) 
Task builder object modules 
Spooler object modules 


Object modules for all the MCR functions except 
BOO and SAV 


Handler object modules 


Executive and SCOM 


File control primitives and file system 
utilities such as UFD and INITVOL. 


System generation 

Bootstraps, 

BOO and SAV MCR functions 

Virtual install INV build command files 
EDI object modules 


System test tasks 


Batch 

Unsupported software 

Accounting system 

Error logging and diagnostics modules 

Online Preserve, Disk Save and Compress (DSC) 
Cross Reference 

FORTRAN IV compiler 


FORTRAN IV OTS 
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Table 2-2 (Cont.) 
Contents of Auxiliary Media 


CONTENTS 


[11,114] Terminal Handler 


{311,13] Sources for DEMO 


[311,25] Sources for unsupported modules 


{311,114] Terminal handler sources 
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2.3 HARDWARE BOOTSTRAPS 

Five models of hardware bootstraps are available on systems used for 
RSX-11D: MR11-DB and BM792-YB and the Massbus bootstraps BM873-YA, 
BM873-YB, and M93@1-YC. The type of bootstrap for a particular PDP-1ll 
can be determined by consulting the equipment order. 

Whenever a request to bootstrap the system is encountered in the 


following text, refer to one of the five sections that follow to 
perform the appropriate bootstrap. 


2.3.1 MR11-DB Bootstrap 
Perform the following steps to use an MR11-DB Bootstrap. 

1. On the console switches, set HALT. 

2. Set ENABLE. 

3. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 2-3 provides the 
device addresses. 

4. Press LOAD ADDR. 

5. Press START. 


Table 2-3 
Device Addresses for the MR11-DB Bootstrap 


DEVICE ADDRESS 


RP@3 Disk 173154 
RK Disk 173118 


RF Disk 173109 


TU1® Magnetic Tape| 173136 (7 or 9 Channel) 


DECtape 1731286 
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2.3.2 BM792-YB Bootstrap 
Perform the following steps to use a BM792-YB Bootstrap. 

1. On the console switches, set HALT. 

2. Set ENABLE 

3. Enter 173188 into the display switches. 

4. Press LOAD ADDR. 

5. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 2-4 provides the 
device addresses. 

6. Press START. 


Table 2-4 
Device Addresses for the BM792-YB Bootstrap 


DEVICE ADDRESS 


RP@3 Disk 176716 
-RK Disk 177406 
RF Disk 177462 


DECtape 177344 


NOTE 


Magnetic tape cannot be booted with the 
BM792-YB Bootstrap. 
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2.3.3 BM873-YA Bootstrap 
Perform the following steps to use the BM873-YA Bootstrap. 
1. On the console switches, set HALT. 
2. Set ENABLE. 
3. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 2-5 provides the 


device addresses. 


4. Press LOAD ADDR. 


NOTE 
If a unit other than @ contains’ the 
device to be booted, set the switch 
register to the unit number of the 
device to be booted before’ pressing 
START. 
5. Press START. 


Table 2-5 
Device Addresses for BM873-YA Bootstrap 


DEVICE ADDRESS 


(RFn disk) 773986 
(RP93 disk) 773190 


(RK#@5 disk) -- Unit @ 7736198 


Unit specified in switch register 773628 


(DECtape) 773038 


(TU1® magnetic tape) 773058 


2.3.4 BM873-YB Bootstrap 


Perform 


1. On the console switches, 


GETTING ON THE AIR 


set HALT. 


the following steps to use the BM873-YB bootstrap. 


the 


2. Set ENABLE. 

3. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 2-6 provides 
device addresses. 

4. Press LOAD ADDR. 

NOTE 

If a unit other than 9 contains the 
device to be booted, set the switch 
register to the unit number of the 
device to be booted before pressing 
START. 

5. Press START. 

Table 2-6 


Device Addresses for BM873-YB Bootstrap 


DEVICE ADDRESS 


(RS#3,4 disk) 
Unit specified 
(RK#95 disk) -- 
Unit specified 
(RP@4 disk) -- 
Unit specified 
(RP@3 disk) -- 
Unit specified 
(RS11 disk) 
(DECtape) 


(TU1® magnetic 


-- unit @ 


in switch register 
unit @ 
in switch register 
unit @ 
in switch register 


unit @ 


in switch register 


tape) 


(TU16/TM@2 magnetic tape) 


773880 
773882 
773632 
773032 
773328 
773322 
773358 
773352 
773136 
773078 
773118 
773158 
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2.3.5 M9361-YC Bootstrap (PDP-11/78 Only) 


The M93@1-YC bootstrap operates only on the PDP-11/70. Perform the 
following steps to use this bootstrap. 


1. Press the HALT switch and set back to the ENABLE position. 
2. Set the start address of 1777658988 in the console switches. 
3. Press LOAD ADDR. 

4. Set the device unit number in switches @ through 2. 


5. Set the device code in switches 3 through 6. Refer to Table 
2-7 for device codes. 


6. Ensure that switches 7 through 21 are off (down). 


7. jbPress START, 


NOTE 


Before the M9391-YC bootstrap actually 
boots the system, it performs CPU tests, 
instruction and addressing tests, and 
memory and -cache tests. If a hardware 
failure is detected, the diagnostic 
program halts. The lights contain the 
ROM address of the halt. If this 
occurs, call the DIGITAL field service 
engineer. 


It may, however, be possible to continue 
with the bootstrap operation if the 
lights contain the address 17773764, 
which indicates a cache failure. To 
continue in this case, press CONT. This 
is the ONLY case in which it is possible 
to continue bootstrapping after the 
diagnostic detects an error. 


Table 2-7 
Device codes for M93@1-YC Bootstrap -- Switches 3 through 6 


DEVICE CODE 


TM11/TU1@® Magnetic Tape 


TC11/TU56 DECtape 


RK11/RK@5 DECpack Disk Cartridge 


RP11/RP@3 Disk Pack 


RH70/TU16 Magnetic Tape 


RH7@/RPO4 Disk Pack 


RH7@/RSG84/RS0@3 Fixed Head Disk 
NOTE 


The M93@1-YC bootstrap is capable of relocating its input 
to various banks of memory. However, it is not possible 
to do this with RSX-11D. An RSX-11D systemmust be located 
as defined during system generation. 
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2.4 TERMINAL HANDLER GENERATION 
2.4.1 Introduction 


Before phase 1 of system generation is performed it is necessary to 
build the terminal handler to reflect the configuration of terminals 
in the system, unless the single terminal handler (TT@1) is to be 
used. There are two files which must be edited. Of these 
[311,114]PARAMS.MAC, describes in general terms the facilities 
required, the number of each type of interface in the system etc. 
{311,114]CONFIG.MAC describes each interface in detail and how every 
terminal is connected. Once these files have been set up the handler 
must be assembled and built as described in Section 2.4.4. 


2.4.2 Editing PARAMS.MAC 
This file is divided into three parts: 


is Assembly parameters which must be set up for every system 
(see Table 2-8). 


Pa Assembly parameters which will not normally need to be 
changed. The values in the second column of Table 2-9 are 
those in the software distributed by DIGITAL. They may need 
to be changed to suit the particular needs of some 
installations. 


3% Assembly parameters whose definitions must not be changed. 


2.4.3 Editing CONFIG.MAC 


This file is in two parts, the interface descriptions and the terminal 
descriptions. Each interface is described by a line of the form: 


INTF number ,type,epa,vec[,extra] 


number is the interface number. The first interface must 
be number @, and the remainder must follow in 
consecutive ascending order. Interface @ must be 
the console DL11. 


type is the interface type, selected from DC, DH, DJ, 
_ DL, DM, DZ. 


epa is the external page address of the first register 
of the interface; e.g., 17756@ for the console. 


vec is the address of the first interrupt vector 


extra may be absent. It is used to contain interface 
dependent information, as follows: 


DC - indicates the type of DCll 
- DCIIAX 
- DC11AA 
- DC11AB 
DC11AC 
- DC11AD 
- DC1I1AE 
- DC11AG 
- DC11AH 


SOO ®m GDNF S 
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DH - if the DH11 has a corresponding DM1l for 
dialup line control, this must be the 
number of the DM1l1 interface. The DMll 
must precede the DH11 in this file. 


DL - If ‘extra’ is present and non-zero, the 
interface is a DLIIE. 


Each terminal is described by a line of the form: 


TERM 


number 


intnum 


subline 


type 


speed 


dialup 


char 


number, intnum,Subline,type,speed,dialup,char 


is the terminal number. The first terminal must 
be number @, and the remainder must be in 
consecutive ascending order. 


is the number of the interface (in the previous 
section) to which this terminal is connected. 


for terminals connected to multiplexor interfaces 
this is the subline number on the interface. For 
singqle-line interfaces it may be left blank. 


is the type of the terminal, selected from: 

AS33 (ASR33), KS33 (KSR33), AS35 (ASR35), L38S 
(LA38S), L3@P (LA3@P), LA36, VT@5, VT58, VT52, 
vVT55, VvT6l1l. If the terminal is not one of these 
DEC-supported models, the type should be given as 
“USR@” and the ‘char’ parameter (below) used to 
describe its characteristics. 


If the default speed for the terminal is to be 
used (see Device Handlers Reference Manual, Table 
2-3), this may be left blank. Otherwise, it 
should be a number which is’ the baud rate of 
terminal or, for a split-speed line, two numbers 
separated by a comma and enclosed in angle 
brackets, with the keyboard (lower) speed first, 
e.g. <150,24900>. 


if the terminal is connected to a dialup line this 
parameter must be the string “DIALUP” otherwise it 
should be blank. 


If any of the terminal characteristics are to be 
non-standard they may be specified here. The 
parameter is a list of pairs of characteristic 
names and values; e.g., <<chl,@>,<ch2,3>, <ch3,1>>. 
The names are those specified in the Device 
Handlers Reference Manual, Chapter 2, Table 2-2. 
The value may be any acceptable value as specified 
in that table. The number of pairs allowed in 
this list is limited only by the length of the 
line. If still more are needed an alternative 
form of the TERM macro may be used: 


TERMBG number,intnum,subline,type,speed,dialup 
SETFLD chl,vall 


SETFLD chn,valn 
TERMED 
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A separate line must be used for each 
characteristic. 


An example CONFIG file is given as Appendix A. a This example applies 
to a system with: 


dis LA36 as a console. 
Ze DH11 interface with five VT5@s and three LA39@#Ss. 


36 DH11 interface with associated DM1ll for dialup lines, with 
six dialup lines set up as ASR33s and two local VT@5s, one 
running at a non-standard low speed. 


4. A DLI1E dialup line set up as a LA36. 


Ds A DJ1l1 with two low speed hardcopy terminals and _ two 
high-speed terminals, connected to different fovr-group 
sublines. 


6. A DL11 line with a special, non-standard terminal running at 
158@/1200 bavd, split-speed. 


2.4.4 Building the Handler 

The following commands should be used to bvild the handler: 
MCR>SET /UIC=[1,1] 
MCR>MAC @[311,114]TTMAC.CMD 


MCROTKB @[11,114]TTTKB.CMD 
NOTE 


The TKB operation will result in four 
“undefined symbols” messages, for the 
segments TT, INIT, IDLE and LINES. The 
exact number of undefined symbols in 
each message will depend on the assembly 
parameter files. 


If the assembly parameter files have been set up incorrectly it is 
possible that some assembly errors will be reported. It is possible 
to check for these first, to minimise wasted time, using the command 
file [311,114] TTMACCHK.CMD. This will assemble only the modules which 
can produce errors. If the CONFIG file is changed but not PARAMS, for 
example because some interfaces have been relocated in the external 
page, CONFIG may be assembled using the command file 
[311,114] CONFIGMAC.CMD. 


The normal version of the terminal handler is overlaid, one overlay 
segment containing the code to deal with I/O requests and the other 
containing the initialization and powerfail code. This means that the 
handler has to access the disk on which it is resident when the system 
is booted or during powerfail recovery. For some applications this 
May not be practical in which case it is possible to build a 
non-overlaid version. This is used, for example, in the distribution 
kit where there is no system disk to read overlays’ from. The 
non-overlaid handler may be built using the TKB command file 
[11,114] TTUNOVR.CMD. In this case the symbol OSSVR in PARAMS.MAC must 
be @. It is recommended that ISSERM also be @ so that space is not 
used to store the initialization error messages. 


2-15 
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Table 2-8 
Terminal Handler Group 1 Assembly Parameters (2.4.2) 


See section 2.4.2 


Name B if Meaning 
Binary 


USSNTS Maximum number of terminals to be serviced. 


BS$22 =] if 22-bit support reovired; must be set on 
PDP-11/7@ configurations with more than 124K 


words of memory. 


“Bells and Whistles’. This should  =1 unless 
space is at a premium. If it =@ the features 
in Table 2-19 will all be omitted. 


BS SAW 


BSSLCK 


=] for Block-Mode terminal support. 


DSSCll Number of DCll single-line interfaces in the 


configuration. 


D$$CDU =l1 if any DCll interfaces are connected to 


modems for dial-up support. 


Number of DH11 16-line NPR multiplexor 
interfaces. 


DSSH11l 


DSSIAL Dialup Support. =l1 if any dialup lines 
reoguired in the system. =@ causes system to 


ignore dialup lines. 


Number of DJ11 16-line interfaces in the 


configuration. 


DSSJ11 


DSSL11 Number of DL11 single-line interfaces in the 


configuration. 


DSSLDU =] if any DLI1(DLI1E) interfaces are connected 


to modems for dialup support. 


Number of DM11BB 16-line modem control 
interfaces in the configuration. These 
interfaces provide dialup support for lines 
interfaced through DHlls. 


DSSM11 


Number of DZ11 S8-line interfaces in the 


configuration. 


D$$2Z11 


D$$ZDU 


=] if any D211 interfaces are connected to 
modems for dialup support. 


=]1 if handler is to recognize and parse escape 
seguences. (see IAS/RSX-11D Device Handlers 
Reference Manual, Section 2.6). 


ESSEQ 


HSSRTZ Clock frequency (5@., 60. or 10@.). The . is 


necessary and indicates a decimal number. 


TSSAPE =] if low speed paper tape is required. 


=§ if no low paper tape is required. 
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Table 2-9 
Terminal Handler Group 2 Assembly Parameters 


See Section 2.4.2. 


Name Normal Meaning 
Setting 


BSSSCN =BSSAW =1 to allow typeahead CTRL/R and Backspace Over 
Tab. 


BSSSP =BSSAW =1 for support of terminals with hardware 
backspace. If it = @, backspace will be output 
but the handler will lose track of terminal’s 


horizontal position. 


DSSHSF =BSSAW&DS$SH11&BSSLCK 


=] If support of DH11 Silo Fill is  reqouired. 
This should be used if block mode terminals are 
present to reduce the number of interrupts. 


DSSKIL =G =@ for notification of termination of requests 


by IO.KIL. 


DSSRAT Default Read-ahead Processing Type, viz. 


8 Type-ahead is illegal and will be ignored. 


1 ‘Deferred Processing” Mode. Characters 
typed ahead will only be processed when they 
are read. Thus RUBOUT, CTRL/U etc. will 
not be seen until a read is performed. 


“Immediate Processing, Deferred Echo’ Mode. 
Characters are processed as they are typed 
but not echoed till they are read. Echo is 
therefore a “clean copy’. 


“Immediate Echo” Mode. Characters will be 
echoed as they are typed, and not echoed 
when they are read. See also the IAS/RSX 
Device Handlers Reference Manual, Section 
2202 


NOTE 


Read-ahead type can be changed in the 
configuration file for particular lines. 


ESSALT =] =] if ALTMODE is to be echoed as ‘S” followed 
by carriage return, =@ if ALTMODE is not to be 


echoed. 


HSSOLD =BSSAW =] for support of VT5x hold-screen mode. This 


support is provided automatically if ESSEQ=1. 


ISSERM =l1 to generate initialization Error Messages 


(see Section 2.4.5). 


L$$30S =] to support LA3@S Serial DECwriters. 
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Table 2-9 (Cont.) 
Terminal Handler Group 2 Assembly Parameters 


Name Normal Meaning 
Setting 


MSSANS 


Time, in seconds, to wait after sensing first 
ring before answering the phone. The 
parameters MSSANS through MS$WCR are described 
more fully in the IAS/RSX-11D Device Handlers 
Reference Manual, Table 2-5. 


Time in seconds, to wait after answering the 
telephone before applying carrier. 


MSSCAR 


Time, in seconds, to wait for a confirming ring 
Signal. If a ring siqnal is not detected in 
this interval the caller is assumed to _ have 
hung up. This time must be greater than the 
period of the ring cycle (3 seconds in USA). 


MSSRNG 


=l1 if UK-type Short Modem Timeouts’ required. 
Some countries, including the UK, require a 
line to be dropped within a very short time 
after detecting carrier loss, because their 
mocgems and some acoustic couplers do not 
distinguish carrier from dial tone. This 
facility is not available for modems interfaced 
via a D211. 


Time, in seconds, to wait for caller to apply 
carrier after the system has applied carrier. 
This allows the caller time to place the phone 
in its bed on an acoustic coupler, without 
tying up the line for too long when a wrong 
number is dialled and then cancelled. 


Time to wait after carrier loss before assuming 
caller has hung up. If MSSUK (above) =@, this 
time is MS$$WCR seconds. It should allow for 
the phone being disturbed on the bed of an 
acoustic coupler or for dropouts on the line. 
If MSSUK =1, this time is MSSWCR clock ticks. 
It should be such that the line iS guaranteed 
to be dropped in the reguired time. 


MSSWCR 


MSSPRI 


Priority of Interrupt Service Routines. =5 
unless there are no multiplexor interfaces in 
the system, in which case it can =4. It may be 
useful for configurations with no _ block-mode 
terminals to use a BR4 Jumper in DH11/DJ11/D211 
interfaces to improve the service to disks etc, 
when MSSPRI should be changed accordingly. 


=BSSSAW ‘Newline’ terminal Support should =1 for 
support of terminals which treat code 12 
(octal) as “Newline” rather than “Line Feed’ 
and have a ‘newline’ key instead of ‘carriage 


return’. 


Total number of 16-word nodes in handler’s 
internal node pool. 


NS$SODS (see text) 


Nodes are picked from the pool for all internal 
buffering. This includes type-ahead, reads, 
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Table 2-9 (Cont.) 
Terminal Handler Group 2 Assembly Parameters 


Name Normal Meaning 
Setting 


writes and the saving of default values when 
terminal characteristics are reset. 


The distributed handler calculates the value 
from USSNTS (Table 2-8) thus: 


For USSNTS from @® to 5 allow 5 nodes per 
terminal. For each terminal from 6 to 32 allow 
3 more nodes. For each terminal beyond 32 
allow 2 more nodes. 


=]1 to build overlaid version of handler. The 
handler should normally be overlaid (see 
section 2.4.4). 


SSSCHR =BSSAW =] to enable ‘set characteristics” function 
(see IAS/RSX-11D Device Handlers Reference 
Manual). The MCR TER command relies on this 
function. The function uses over 1/2K words of 


memory and may be omitted for small systems. 


=SSSCHR =1. to enable ‘get characteristics” subfunctions 
of ‘set characteristics’ (SF.GSC, SF.GMC, see 
Device Handlers Reference Manual, Sections 
2.4.3.5, 2.4.3.6). Allows applications programs 
to determine characteristics of terminal on 
which they are running. 


DSSCHR =SSSCHR =] to enable dump characteristics subfunction 


(SF.GAC, SF.SAC in IAS/RSX-11D Device Handlers 
Reference Manual, Sections 2.4.3.7, 2.4.3.8). 
Allows application programs to change terminal 
characteristics and restore them on exit. 


RSSBTB =BS$SAW&BSSSCN 


=] to enable scope tab rubout. Rubout over tab 
then moves cursor to where it was before tab 
was typed. 


=8 saves about 68 words but rubout over’ tab 
then echoes as backspace-space-backspace. 


=BSSAW =] for software simulation of form feed and 

vertical tab. On terminals with 
characteristics set correctly this will replace 
a token output of a fixed number of line feeds. 
Used for example when a slow high-guality 
printer is connected via a terminal interface. 


VSSFIL =] =l1 sets VT@5-type vertical fill (see Device 
Handlers Reference Manual). =] is reguired if 


any VT@5 is configured in the system. 
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Table 2-19 
Parameters Dependent on BSSAW in the Handler as Distributed 


Parameter Meaning | Parameter Meaning 


BSSSCN HS$OLD 
see 
Table 
2-9 


BS$SP ISSERM 


NSSL 


DSSCHR 


DSSHSF RSSBTB 


SSSCHR 


GS$SCHR 


SSSFF 
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2.4.5 Terminal Handler Error Messages 


The terminal handler performs some checking of the consistency and 
sense of the parameters used to build it. Some of these errors are 
detected at assembly time, as described above. Others cannot be 
detected until the handler becomes active, at the beginning of System 
Generation Phase 2. These are printed when the system is first 
bootstrapped, and have the form: 


TT.... *FATAL* error message 


If the error is related to a particular terminal or interface, its 
number is printed after the message. After this message, SGN2 will 
print: 


UNABLE TO FIND ATL FOR TERMINAL HANDLER(TT....) 


The system is not usable, and the terminal handler must be rebuilt 
correctly and System Generation repeated. 


The handler abandons initialization as soon as an error is found. For 
this reason if more than one error condition is present, only the 
first is reported. 


Exceptionally, the message “FAILED TO ALLOCATE UNIBUS MAP REGISTER’ 
may be output when a system is booted after System Generation, if it 
is moved to a system with more than 124K of memory after running on a 
smaller system. 


Error message texts: 
DH11 MODEM INTERFACE IS NOT A DMlil 


The interface specified as the ‘extra’ parameter for a DH1l1 is 
not a DMll. 


DH11 MUST FOLLOW CORRESPONDING DM11 


The interface specified as the ‘extra’ parameter for a DH1l has a 
number greater than that of the DH11. It is essential that the 
DM1l precede the DH11 so that initialization can be performed in 
the right order. 


FAILED TO ALLOCATE UNIBUS-MAP REGISTER 


On a PDP11-78 with more than 124K of memory, the handler needs to 
allocate a Unibus Map Register (UMR) to serbice DH11l lines. If 
all of the 31 available registers are in use by other handlers, 
this messate will occur. Normally, this will only occur if the 
system is moved forma small (<124K) machine to a larger one, if a 
large number of Unibus NPR devices (e.g. RK, TU1@, RP@3) are on 
the system. 


FAILED TO CONNECT TO INTERRUPT VECTOR 
Two conditions may cause this error: 
1. There is an error in the CONFIG file such that more than one 


interface is specified as having the same interrupt vector 
address. 
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2. Another handler is connected to one of the interrupt vectors 
specified in the CONFIG file. Htis indicates an error either 
in CONFIG or in the parameters supplied to Sysgen l. 


The message indicates an error either in CONFIG or in the 
parameters supplied to phase 1 of system generation. 


FAILED TO DECLARE HANDLER 


Another version of the handler, or another terminal handler, is 
already active. 


FAILED TO DECLARE POWER FAIL AST 
This error should not occur. It may do if the terminal handler 
build file is changed to reduce the node pool limit of the 
handler. 

ILLEGAL DC1l SPEED TYPE 


The speed type of a DCl1l interface, specified as the ‘extra’ 
parameter, is not in the range @-7. 


LINE SPEED NOT VALID FOR THIS INTERFACE 
The speed specified for a terminal, | either implicitly by the 
terminal type or explicitly as the “speed” paramerer to the TERM 
Macro, iS not available on the specified interface. This will 


occur, for example, if a VT5@ is connected to a DCll without an 
explicit speed specification suitable for the interface. 


MORE THAN ONE DH11 REFERS TO ONE DM1l1 


More than one DHI1 interface has specified the same speed 
specification suitable for the interface. 


MORE THAN ONE DH11 REFERS TO ONE DM11 


More than one DH11 interface has specified the same DM1ll modem 
control interface as the “extra” parameter. 


MORE THAN ONE TERMINAL ON SINGLE-LINE INTERFACE 


More than one terminal has specified the same _ single-line 
interface. 


NO MODEM INTERFACE FOR DIALUP LINE 


A terminal has the “dialup” parameter set but the interface to 
which it is connected has no dialup capability. 


SLAVE INTERFACE USED AS PRIMARY INTERFACE 


The interface specified for a terminal in the TERM macro is a 
DMl1l. 


TWO TERMINALS ON SAME SUBLINE 


More than one terminal has specified the same subline of the same 
multiplexor interface. 


CHAPTER 3 


SYSTEM GENERATION PROCEDURES 


RSX-11D provides a system generation capability that consists of two 
tasks (phase 1 and phase 2) and a set of command files. The first 
phase can be performed online independently of the target hardware or 
software configuration. Its purpose is to create a file on disk that 
is an RSX-11D system capable of running on the target hardware 
configuration. 


Phase 2 of system generation is designed to perform those functions 
that require the target configuration. Phase 2 is a task that is 
activated in the system created by phase l. 


If the generated system is being written onto the current system disk, 
i.e., if a target disk is not being used, system generation must not 
be performed online with other system operations. 


Both phases accept input from command files. Phase 1 also accepts 
input from a terminal. Chapter 5 details the procedures for phase 1 
input from a terminal. The distributed system includes several system 
generation command files under UFD [11,17]. The command files that can 
be used as input to phase 1 all have the following format for the 
filename and type. 


diskznnK.CMD 


disk indicates the disk that is to be the system device, i.e., 
RK@5, RK®96, RP#2, RP#3, RPO4, RPO5, RPM. 


z indicates the programmable clock (P) or the line frequency 
clock (L). 


nn indicates the size of the save image in units of 1K words 
Any one of these files can be used as input to phase l. 
Appendix A provides a sample listing of the files. 


The phase 2 input file is SYSBLD.CMD unless an alternative is 
specified by the SYSBLD directive in phase 1. It is located under UFD 
[11,17]. Phase 2 automatically uses this file to create a_ running 
system on the target hardware. SYSBLD.CMD can be edited prior to 
running phase 2 to reflect local requirements. Appendix A contains a 
listing of SYSBLD.CMD. 
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NOTE 


SYSBLD.CMD contains numerous comments 
that provide the user with information 
about the functions of that file. The 
user is advised to read these comments. 


3.1 PHASE 1 OF SYSTEM GENERATION 


Phase 1 of system generation can be run by a privileged user from any 
terminal on the host RSX-11D system. Like system utility programs, it 
uses the defaults of the system under which it is running and 
communicates with the user on the terminal from which the user 
requested it. The purpose of phase 1 is to create a file on a disk. 
Once the file is created, the disk is called the taraqet system disk. 


It is preferable that the target system disk be a disk other than the 
host system disk (SY@). When a separate disk is used, phase 1 becomes 
an online procedure that does not affect the running system. 


If the target system disk and the host system disk are the same, phase 
1 should not be performed online with any other operation because 
several tasks are installed in the target system during phase 1 that 
also are installed in the host’ system. Since task headers are 
modified by the install function, a task installed in one operating 
system cannot be used in another even though it was installed there 
previously. Device assignments, for example, may be different. 


NOTE 


Throughout the RSX-11D document set, the 
use of lower case letters in command 
strings indicates that the user is to 
Supply the appropriate variables at that 
point in the command. For example, in 
the following MCR command, the user is 
to specify the device type and unit of 
the target disk. 


MCR>MOU target disk 
could be typed as 
MCR>MOU DK1: 
The procedures for executing phase 1 of system generation on a running 
RSX-11D system follow. 


1. Install system generation phase 1 and the virtual install 
function as follows. 


MCR>INS [11,1]SGN1 
MCR>OINS [11,1] INV 


4. 
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If 


the target disk is the current system disk, go to step 5. 


If steps 2 through 4 have been done previously, go to step 5. 


Otherwise, 


MCR>INI target disk 
MCR>MOU target disk 
Create the required UFDS on 


following commands. 


MCR>UFD target disk [1,1] 


MCR>UFD target disk [1,2] 


MCR>UFD target disk [1,3] 


MCR>UFD target disk 


MCR>UFD target disk 


MCR>UFD target disk 


MCROUFD target disk 


MCROUFD target disk 


MCR>UFD target disk 
Transfer all files 
target disk and the 


enabled. 


current 


MCR>SET /UIC=[1,1] 


MCR>PIP target disk=*.* 
MCR>SET /UIC=[1,2] 
MCR>PIP target disk=*.* 
MCR>SET /UIC=[11,1] 
MCR>PIP target disk=*.* 
MCR>SET /UIC=[11,17] 


MCR>PIP 


{11,1} 
[11,17] 
[200,266] 


reguired for the target system. 


target disk=*.TSK, 


initialize and mount the target disk, as follows. 


Use any 
options. 


appropriate INITVOL 


Use any 
options. 


appropriate MOUNT 


the target disk using the 


(some system files and 
libraries) 
(error message files) 


(for Verify) 


[1,4] /PRO=[RWED,RWED,RWED, RWED] 


(to allow spooling) 


[1,5] /PRO=[R,RWED,R,R] 


(for accounting) 


[1,6] /PRO=[RWED,RWED,RWED, RWED] 


(for error logging) 

(system tasks) 

(system generation files) 
(an optional user UFD) 


Both the 


system disk must be write 


*.CMD,*.STB 
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Prepare the required phase 1 input command file. Several 
files are provided with the distributed system. 


Depending on the available pool size of the host system, it 
May be necessary to remove some tasks from the host system. 
Section 5.2.7 provides guidelines for calculating node pool 
usage during system generation. 


A file under [11,17] called SYSGENREM.CMD can be used to 
remove tasks. It is advisable to use this file. However, if 
others are uSing the system, care should be taken not to 
remove tasks they require. Enter the following command to 
remove installed tasks using SYSGENREM.CMD. 

MCR>REM @[11,17]SYSGENREM 


Run phase 1 ensuring that the command is terminated by 
pressing ALTMODE. 


MCR>RUN SGN1 Depress ALTMODE. 
The system responds as follows. 

SYSGEN PHASE 1 

SPECIFY TARGET DEVICE AND FILENAME 

SGN> 
At this point, the user has the option of naming the device, 
UFD, and filename to be assigned to the file produced by 
phase 1. The directive has the following format. 


SGN>TARGET=td: [ufd] filename 


td indicates the target disk. If it is omitted, 
SY is used by default. 


[ufd] is the UFD of the system image file. If it 
is omitted [11,17] is used. 


filename is the name to be assigned to the file. If 
it is omitted, RSX.SAV is used. 


If the TARGET directive is not specified, the default is 
SY:[11,17]RSX.SAV. This directive may have been included in 
the command file to phase 1. In this case, proceed to the 
next step. 
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18. Name the command file to be processed by phase 1 of system 
generation (SGN1). The command file can be any one of those 
provided with the system, e.g., RP@3L48K.CMD, or it can be a 
user-created file. The following command to SGNI1 is used. 


SGN>@command file specification 


All of the commands read from the command file are printed on 
the terminal. Upon successful completion of the processing 
of the command file, the following message appears on the 
terminal. 


SGN>END OF PHASE 1 
Depress CTRL C to obtain MCR. 


The host system remains usable in the normal way even if 
fatal errors occurred during execution of phase l. 


11. If any errors occurred during phase 1, correct them (consult 
the Messages Appendix) and repeat steps 7 through 190. 


NOTE 


Fatal errors must be corrected, but 
diagnostic messages imply that the 
resulting system may be usable. 


12. Phase 1 of system generation does not produce a target system 
that is hardware bootable; i.e., it does not write physical 
block @ of the disk. 


Do not log off the host system. Consult step 1 of the phase 
2 procedures (Section 3.2) to be able to boot the target 
system. 


3.2 PHASE 2 OF SYSTEM GENERATION 


Phase 1 of system generation has created a file on the target system 
disk. This file contains a memory image of a running RSX-11D system. 


In this system, two tasks are active. One is the system disk handler, 
and the other is phase 2 of system generation. Bootstrapping this 
file into memory causes phase 2 to run. 


NOTE 


For phase 2 to execute successfully, it 
must be booted on a machine with as much 
or more memory than that specified 
during phase l. 


Phase 2 of system generation processes by default a command file named 
[11,17]SYSBLD.CMD. If any modifications need to be made to this file 
or its equivalent to reflect system reguirements, they must be made 
prior to execution of phase 2. If an alternative file has _ been 
specified by the SYSBLD directive in phase 1 this file will be used in 
Place of SYSBLD.CMD. 
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The steps necessary to run phase 2 follow. 


i 


Bootstrap phase 2. There are two ways to bootstrap phase 2 
into memory on the target system. Whichever way is used, it 
must be booted from the unit specified as SY during phase 1. 
Methods a and b follow. 


a. Create a bootstrap block @ on the target disk and use the 
hardware bootstrap. Issue the following command on the 
host system to create bootstrap block @. 


MCR>BOO target disk: filename/WB 


filename is the name previously specified in the 
TARGET directive. 


This command takes virtual block 1 of the file created by 
phase 1 and writes it on physical block @ of the target 
device. The disk is now hardware bootable (see Section 
2.1). It can be taken to the target hardware and booted. 


b. Use the software BOOT function. The MCR software 
bootstrap function is described in the RSX-11D User’s 
Guide. The software bootstrap boots the file created by 
phase 1 into memory in the host system. Block @ of the 
target system is not modified. 


When the software bootstrap function without the /WB switch 
is executed, no other users’ should be online to the host 
system. The host system is overlaid in memory by the target 
system. The host system disk remains unaltered. 


Before issuing the BOOT command, ensure that the target 
system disk is mounted on the unit specified as SY during 
phase 1. Then issue the following command to the host system. 


MCR>BOO target disk:filename 


Notice that the MCR BOOT command can be used either to create 
the bootstrap block on a system disk by including the /WB 
switch or to perform the bootstrapping from any disk by 
omitting the /WB- switch. The two functions are mutually 
exclusive. 


If the bootstrap is currently written for a system image on 
the disk (by means of a previous /WB) it is often advisable 
not to write the bootstrap at this point. Not doing so 
retains the ability to obtain the old system on hardware 
booting. 


Writing the bootstrap here means that such a hardware boot 
would initiate the System Generation Phase 2 image. This can 
be useful if Phase 2 fails for any reason. 


The function BOO is discussed in the privileged user’ section 
of the RSX-11D User’s Guide. Chapter 5 of this manual 
contains a detailed dicussion of bootstrapping. 
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Once the system has been bootstrapped, phase 2 prints’ the 
following message. 


*** SYSTEM GENERATION PHASE 2 *** 


Phase 2 proceeds to mount the new system disk and then open 
and read the file SYSBLD.CMD. All commands encountered in 
SYSBLD.CMD are executed and echoed on the terminal. 


NOTE 


If the terminal handler has been built 
incorrectly it may print an error 
message at this point. In this case 
System Generation phase 2 will fail and 
the system will not be usable. See 
Section 2.4.5 for a list of these error 
messages and their meanings. 


Upon successful completion, phase 2 prints the following 
message. 


*** END OF SYSTEM GENERATION PHASE 2 *** 


Set the time and date, redirect the console logging device 
(CL), load the message output handler, and perform any other 
Similar functions; e.g., loading other handlers. 


MCR>TIM hh:mm:ss dd-mmm-yy 
MCR>RED LP:=CL: 
MCR>LOA MO 


Additionally, to prevent the fragmentation of the GEN 
partition, fix the file primitives using the following 
procedure. 


MCR>DMO SY: Also dismount any other mounted volumes. 

MCR>FIX F11ACP 

MCR>MOU SY:/0VR 
If you are satisfied at this point that the system generation 
was successful, dismount any mounted devices and perform a 
save uSing the MCR SAV command. The following is an example. 


MCR>DMO SY: 
MCR>SAV 


Once the system is saved, the following message is printed on 
the console. 


nnK WORDS RSX-11D Vxxxx 
where: 
nn is the memory size. 
xxxx is the Executive version number. 
At this point, SAV may issue messages describing memory size 
adjustments; see Section 5.5 and the discussion of SAV in 


the RSX-11D User’s_ Guide. The MCR prompt follows’ the 
messages. 
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NOTE 


If at any time before performing the 
SAV, a reboot of the new system disk is 
performed, as described in step 1 above, 
phase 2 of system generation is executed 
again. 


A reboot after a SAV causeS the same 
response as seen after performing the 
SAV above, i.e., nnK WORDS RSX-11D. The 
SAV function is discussed in the 
privileged user section of the RSX=-11D 
Users Guide. 


If the user is satisfied with the system generation and wants 
the disk to be hardware bootable, the functions of step la in 
this section should be performed if they have not been done 
already. 


NOTE 


It may be desirable to have the system 
automatically mount the system disk and 
request the time whenever it is booted. 
This can be done using type ahead after 


dismounting all volumes. It is 

recommended that the type ahead 

procedure be used after a test run of 

Step 6 above. The following is an 

example. 

MCR>DMO SY: Also dismount any other mounted 
volumes. 

MCR>«/or ($) Type either RETURN or ALTMODE 

SAV Type ahead 

MOU SY:/OVR Type ahead 

TIM Type ahead 


At this point, press CTRL/C to cause the save, the 
Sign-on messages, and the execution of those functions 
typed ahead. Typing only a single space after TIM leaves 
MCR ready for the operator to insert the current time and 
date followed by RETURN. The type ahead feature also can 
be used for comments by prefixing the comment with a 
semicolon (;) or an exclamation mark (!), to a maximum 
total of 8@ characters. 


Type ahead is available only on the multiterminal teletype 
handler, not on the single-terminal handler TT@l. 


CHAPTER 4 


SYSTEM GENERATION DIRECTIVES 


Phase 1 and phase 2 of system generation are accomplished by issuing a 
series of commands to the system. The commands issued during phase l 
are called directives and are described in this chapter. Most 
commands issued during phase 2 are MCR commands. One non-MCR phase 2 
directive *DELAY also is described in this chapter. 


Many system generation directives can have multiple parameter sets for 
a single occurrence of the directive name. Multiple sets are 
separated from each other by backslash (\) characters. The examples 
below illustrate two PAR directives first and then the same two 
directives using the convention for multiple parameter sets. 


PAR=JIM,,,U 
PAR=JOHN,,,U 


or 

PAR=JIM,,,U\JOHN,,,U 
The method used to specify these directives to system generation is 
detailed in Chapter 5. Examples of the directives are provided in 


Appendix A. These examples should be used as guidelines in tailoring 
individual systems. 
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4.1 TARGET DIRECTIVE 


The TARGET directive is used to define the target device, i.e., the 
device on which phase 1 is to create its output file and obtain all 
reguired tasks for installation. The TARGET directive has the 
following format. 

TARGET=xyn: [ufd] filename.ext 


xyn: is the device mnemonic and unit number. The 
default is SY@. 


[ufd] is the UFD under which phase 1 is to store the 
system file. The default is [11,17]. 


filename .ext is the filename and extension used to name the 
file created by phase 1. The default is RSX.SAV. 


If the TARGET directive is omitted, phase 1 uses the following file 
specification. 


SY@:[11,17] RSX.SAV 


Only one target specified is permitted. 
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4.2 PDP1l DIRECTIVE 


The PDP1l directive is required to define the target system processor 


configuration 
format 


system generation. The directive has the following 


PDPll=cpu-type, [mem-size] , [fpt-optn] , [clock-freq] 


cpu-type 


mem-size 


fpt-optn 


clock-freg 


nn to specify a PDP-11/nn where nn is 
34,35,49,45,50,55 or 7@. These are the only 
accepted values. 


physical memory size (to be saved and _ booted) 
specified as nnnnK words. nnnn must be a decimal 
integer. If this parameter is omitted, 32K is 
used as the memory size. The mem-size specified 
must be equal to or less than the amount of memory 
on the target hardware. The maximum memory size 
permitted is 124K for a PDP-11/34,35,48,45,58 or 
55 and 1920K for a PDP-11/70. (See Section 5.5.) 


FP to indicate that the PDP-11/34,45,50,55 or 78 
floating point processor option is to be used; 
otherwise, the parameter is omitted. This option 
is illegal for a PDP-11/35 or 46. 


system clock ticks per second for the standard 
clock, or interrupts per second, clock 
identification, and clock ticks per interrupt for 
the programmable clock. 


For the standard clock, specify a decimal number 
that is used as the line frequency (normally 58 or 
68). The system runs with the line frequency clock 
at the specified frequency. If the parameter is 
omitted, 69 Hz is used. 


For a programmable clock, three decimal numbers 
are specified. 


1. Frequency of clock interrupts per second; 
e.g., 1008. 


2. Clock identification 


6 = 100 KHz 

1 = 10 KHz 

2 = line frequency 
3 = external 


3. Number of clock ticks per interrupt 


The three numbers must be enclosed in angle 
brackets and separated by commas as_ in the 
following example: 


<180,9,1008> 


The above example indicates that the programmable 
clock is to be used as the system clock. It is 
interrupting 18@ times per second using the 190 
KHz clock with a count of 1888 loaded into the 
count register. 
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4.3 EXEC DIRECTIVE 


The EXEC directive is used to load the RSX-11D Executive into memory 
Starting at a specified 32-word boundary. An address higher than’ the 
bootstrap program must be used. See Section 5.4.1 for bootstrap 
sizes. 


The EXEC directive has the following format. 
EXEC=base 


base = a 32-word boundary at which the Executive is to 
start. The octal number specified in the EXEC 
directive is multiplied by 188 (octal) by system 
generation to determine the starting address. For 
example, if base is specified as 548, the starting 
address is memory location 54988 (octal). 


The EXEC directive is optional. If the EXEC directive is not 
included, the Executive Starts at the next 32-word boundary after the 
bootstrap program and base addresses specified in subsequent 
directives are ignored. 


If the EXEC directive is included, a base address must also _ be 
specified in every directive that contains base as_ an optional 
parameter. 


If a PDP-11/78 system in excess of 124K is being generated, the 
Executive, SCOM, and system disk partition must be positioned 
completely below the 124K boundary. Furthermore, the partition into 
which SGN2 is installed must have sufficient space below the 124K 
boundary for SGN2 to fit completely. Phase 1 checks for all the above 
conditions and issues an error message if any is violated. 
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4.4 SCOM DIRECTIVE 


The SCOM directive allocates space for the system common area. The 
system common area comprises the system subroutines; a communication 
region; the system tables, including the system task directory; and 
the node pool. The system common area cannot exceed 12K words. 


The SCOM directive has the following format: 
SCOM= [base] ,size,std-entries 


base = starting address for the system common area. This 
location is specified using the same conventions 
as for the base address in the EXEC directive. If 
the EXEC directive is included in system 
generation, the base parameter must be part of the 
SCOM directive. If this parameter and the EXEC 
directive are omitted, the system common area 
follows the Executive in memory. 


size = total length of the system common area. The size 
can be specified as an octal number of 32-word 
blocks or as nnK. When the form nnK is used, the 
number (nn) is multiplied by 1824 words to 
determine the desired size. The factors involved 
in determining the size of SCOM are detailed below 
in Section 4.4.1. 

std-entries = decimal number of system task directory entries. 
This parameter establishes the maximum number of 
simultaneously-installed tasks (user and system 
tasks) that the system is to support. 


One SCOM directive is required. 


4.4.1 SCOM Size 


The size of the system common area (see Section 4.4) is the sum of the 
following elements: 


l. The length in words of the system subroutines’ and the 
communication area. This is calculated as follows: 


Subroutines Size = (168900 - .CRTSK)/2 words (octal) 


2. The number of tasks installed at any given time multiplied by 
16 words, 


3.. The number of system task directory (STD) entries specified 
by std-size, above, 


4. The number of DEV directives multiplied by 25 words, 
5. The number of PAR directives multiplied by 1@ words, 
6. Size of the variable-length node pool. 


To determine the approximate amount of remaining space in the _ pool, 
subtract items 1] through 5 from the SCOM size parameter as follows. 


Pool size = SCOM size - (sum of items 1 through 5) 
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The node pool is used by the Executive and many of the system 
utilities as dynamic storage. Each node consists of a variable number 
of 8-word blocks. If the system runs out of pool. space, its 
performance degrades and results may be unpredictable. Until 
experience is gained with the system, leave as much space as possible 
for the pool. 
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4.5 PAR DIRECTIVE 


The partition directive establishes the name, base address, size, and 
type of every partition in the target system. Every partition in the 
system must be defined during system generation. 


The PAR directive has the following format. 
PAR=par-name, [base] ,size, [par-type] , [par-pri] 


par-name = up to 6 character ASCII name for the partition. 
It is converted to a radix 5@ name by the system. 


base = an optional starting address for the partition. 
This parameter is specified only if a base address 
is included in the EXEC directive and follows’ the 
same rules as those for the EXEC directive. 


If base is omitted, the system places’ the 
partition optimally in memory. 


size = the size of the partition specified as an octal 
number of 32-word blocks or as nnK. When nnkK is 
used, nn is multiplied by 1824 to determine the 
desired size. 


One partition in the PAR specifications can 
contain an asterisk (*) instead of an actual size. 
The size of that partition is the remainder of 
memory after the bootstrap, Executive, SCOM, and 
all specified partition sizes have been subtracted 
from the memory size stated in the PDP11 
directive, 


par-type = partition type. U indicates user-controlled; S&S 
indicates system-controlled; and T indicates that 
the time-based scheduler is to operate in this 
partition. This algorithm is described in the 


RSX-11D System Manager’s Guide. If par-type is 
omitted, the partition is user-controlled. 


par-pri = is the priority at or above which the time-based 
scheduler declares a task to be runnable. It is a 
decimal value in the range 2 through 2@@ (PR.A for 
the minimum and PR.C for the maximum, 
respectively). This parameter is valid only for 
T-type partitions. If par-pri is not specified 
for T-type partitions, a default value specified 
by the Executive global symbol PR.DFL is used. 
PR.A, PR.C and PR.DFL are described in the RSX-11D 
System Managers Guide. 


Multiple parameter sets are allowed. 


Unless base addresses are specified, the partitions are placed in 
memory in the order specified by the set of PAR directives. 


If PDP-11/78 generation is being performed, the system disk handler 
and SGN2 must be completely below the 124K boundary. Refer to Section 
5.5 for a discussion of partitioning under RSX-11D. 


Only one partition can use the asterisk (*) size specification. Any 
number of U, S, and T partitions is permitted. At least two 
partitions are required: one for the system disk handler and one _ for 
system generation phase 2. 
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4.6 DEV DIRECTIVE 


The DEV directive is used to characterize completely each device to be 
controlled. Each use of DEV creates an entry in the system’s Physical 
Unit Directory (PUD). Any device not defined by a DEV directive does 
not exist as far as RSX-11D is concerned. 


Often with DEV it is enough to specify the device mnemonic with its 
number and the device type. See Appendix A.2 for examples. 


If a device is to have non-standard characteristics, the latter can be 
specified in place of a standard type. See below under ‘type’ and 
Appendix B for details of device characteristics. 


A device’s interrupt trap vector, software priority and external page 
address may also be taken by default. The default values are listed 
in Table 4-1. 


With a device there can be associated a file primitives task or 
ancillary control processor task. See below under “devacp’. 


The format of the DEV directive is as follows. 
DEV=xyn,type[, [vect], [pri], lext-page] [,devacp] ] 


xy a 2-character ASCII mnemonic to be used to refer 
to the device. 


n a l-or 2-digit octal unit number. 


type either a device type that phase 1 uses to 
determine the device characteristics or the actual 
device characteristics. Table 4-1 lists the 
device types recognized by phase 1. Appendix B 
lists the associated characteristics. 


If the four device characteristics are to be 
specified they must appear between angle brackets 
as in the following example. 


DEV=XY@,<3,17,21,1000>,218,5,177008 


vect the device interrupt trap vector. See Table 4-1 
for the default values. 


pri the software priority at which the device 
interrupts are to be serviced. The user should 
ensure that the software priority is equal to or 
higher than the hardware level at which the device 
interrupts unless the interrupt service routine of 
the handler is re-entrant. See Table 4-1 for the 
Gefault values. 


ext-page the external page address of the device 
controller. In most cases, ext-page is the lowest 
address when a device uses several external page 
addresses. See Table 4-1 for the default values. 


devacp is an optional file primitives task name or ACP 
name for file-oriented devices. 


An ACP (ancillary control processor) is a task 
that assists a device handler in managing a 
file-structured volume. An ACP also is referred 
to as a file primitives task under RSX-11D. 


4-8 
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If an ACP is not specified, phase 1 defaults’ to 
FI1ACP for directory devices and MTAACP for 
Magnetic tape. 


If an ACP task is specified, its name must be 6 
characters ending in ACP. The first three 
characters are stored in the PUD and used at mount 
time. The ACP task must be installed before the 
device can be mounted. 


If the vector, priority and external page address are not specified, 
they will be defaulted to the values shown in Table 4-1. 


For examples of the DEV directive see Appendix A.2. 
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Table 4-1 
Device Information 


Normal External 
Mnemonic Type Vector Priority Page Address 
. 220 5 


RK@3 
RK@5 (5) 
RFn (1) 204 
RP#3B,RPG@2 254 
RS@3 204 
RS@4(2) 204 
RP94,RP05,RPO6 (2) 254 
RKG#6 219 
RX@1 264 
CONSOL (3) 69 
TERM Float 
LP11A(88Col) 206 
LP11B(132Col1) 2098 
Lxllyz (4) 200 
CR11 2390 
CD11 239 
TU1®O,TS#3 224 
224 
76 
74 
214 
269 
134 
130 
Float (6) 
234 
None 


177408 


177468 
176718 
172046 
172046 
176780 
177446 
1771798 
177568 
Float 
177514 
177514 
177514 
1771698 
172469 
172529 
172449 
1775598 
177554 
177346 
177508 
172576 
176778 
178480 
171960@ 
None 


ZAHUAAEAHAAAAUUAADHAAAAHLUUNUUUUW 


number of RF11 platters 
These are disks on the RH Massbus controller. 


The DB unit number must correspond to the number assigned by 
physical connection to the RH. 


CONSOL must be used for the console terminal TT@. All other 
terminals must be specified as TERM. 


The line printer type is Lxllyz where 


x for LP1l line printer 
for LP®@5 and LS1ll type printers 


P 
S 
W for wide (132 column) printers 
N 
U 


tou th oueout 


for narrow (88 column) printers 

translate lower case characters to upper case 
(ASCII codes 149-176 are converted to 198-136) 
= L for no translation of characters. 


An RKO5F disk is specified as two RK@5 units. The unit 
numbers must be paired as follows for each RKO5F unit: (DK@ 
and DK1l), (DK2 and DK3), (DK4 and DK5) and (DK6 and DK7). 


For an LPS11 the vector, priority and external page address 
must all be specified. 
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NOTE 


For various combinations of the above 
devices, vector addresses and external 
Page addresses may differ from those in 
Table 4-1. The correct vector and 
external page address for any 
configuration can be determined by Field 
Service Engineers. Useful information 


can also be found in PDP-11 Peripherals 
Handbook. 


4.6.1 Pseudo-Devices 


The following pseudo devices are used in RSX-11D (see Chapter 3 of 
RSX-11D Users Guide): 


SY system disk 

TL terminal interface 
cI console input 

CoO console output 

CL console log 

MO message output 

BP batch 

SP spooling output 


SY, TI, CI, CO, CL are automatically provided. MO, BP and SP if 
required must be declared in phase 1 by the DEV directive, thus 


DEV = MO 
DEV = SP 
DEV = BP 


and can not be added at a later. stage. All except BP may be 
redirected to particular physical devices after phase 2 by the 
MCR>RED[IRECT] command, for example 


MCR>RED DP1:=SP: 


Both BP and SP are required for BATCH processing. SP must be 
redirected to a disk. BP is automatically redirected to the terminal 
invoking batch. This invoking terminal is the one from which batch 
commands are submitted or, in the case of card input, the one from 
which the card-reader handler was loaded. See the RSX-11D BATCH 
Reference Manual, Chapter 4. 
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4.7 SY DIRECTIVE 


The system directive establishes the initial SY of the target system, 
i.e., the system disk to be used when phase 2 of system generation 
runs. The SY directive has the following format. 


SY = xyn 
xy = the 2-character mnemonic of the device. 
n = the unit number of the device. 
The default is DK@. 


Phase ] of system generation checks that the handler task for the 
device designated as SY is installed. For example, if DP@ is to be 
the system device, the user must install the handler DP.... during 
phase 1 of system generation. 


Care must be taken to ensure that the correct device is assigned to 
SY. Phase 1 of system generation assumes that all tasks that phase 1 
installs are to be resident on the SY of the target system and creates 
STDs accordingly. 


Since some of these tasks are required during execution of Phase 2, it 
is necessary to bootstrap phase 2 from the target SY device. See 
Section 5.4 on software bootstrapping of RSX-11D. 
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4.8 DPAR DIRECTIVE 
The default partition directive specifies the partition to be used 
when a partition is not indicated for a task during task building or 
when the /PAR portion of an MCR command is omitted. 
The DPAR directive has the following format. 

DPAR=par-name 


par-name = the name of the default partition. It must be a 
name used in a PAR directive. 


The DPAR directive is reguired. 
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4.9 DUIC DIRECTIVE 
RSX-11D provides the user with an MCR function referred to as RUN S. 
The purpose of this function is to allow a nonprivileged user to run 
any of a set of multiuser tasks that reside under the same UFD on the 
system disk. The DUIC directive is used to designate the UFD that is 
to contain these multiuser tasks; normally, the nonprivileged user 
would not have access to the designated UFD. 
The DUIC directive has the following format. 

DUIC=g,m 

g = the group number 


the member number 


m 


For example, if the directive DUIC=290,291 is issued during system 
generation, any user can run a task having the file specification 
SY: [200,201]task.tsk by entering the following command. 


MCR>RUN Stask 


If the DUIC directive is omitted, UFD [11,1] is used by default when a 
RUN $ command is issued. 


It is the system manager’s responsibility to ensure that all tasks 
that are to be available to the nonprivileged user by means of RUN §$ 
are stored under the UFD designated by the DUIC directive. 
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4.18 CKPNT DIRECTIVE 


The checkpoint directive indicates that checkpointing is to be enabled 
in the system and specifies the disk and disk storage area to be 
allocated for checkpoiting. 


The CKPNT directive has the following format. 
CKPNT=dev,size 


dev = name of the device on which the checkpoint area is 
to reside. The device must be named in a DEV 
directive. 


size = size of the checkpoint area on the disk ‘dev’. The 
size can be specified either as nnK (i.e. words), 
with nn in decimal, or as an octal number of 
32-word blocks. 


For example: 
CKPNT=DK1,50K 

specifies 5@K words on DKl, and 
CKPNT=DK1,1699 


specifies 16@@(octal) 32-word blocks on DKl, that is 168982 (octal) 
bytes. 


The device named for checkpointing must contain a Files-]ll structured 
volume and be mounted during phase 2 of system generation. It may 
also be necessary to install and load the appropriate disk handler 
before creating the checkpoint file. To create a Files-ll structured 
volume, use the INI command to MCR in the SYSBLD.CMD command file that 
is executed during phase 2 of system generation or have ae previously 
created volume on the device. Allocation of the checkpoint file is 
the last function perfomed by SGN2 after processing SYSBLD. 


The use of checkpointing is optional. However, if it is used, real 
memory space is allocated to support it. The amount of memory used 
depends on the checkpoint area of the disk. The relationship is one 
32-word memory block for every 512K words of disk space specified for 
checkpointing. The checkpoint bitmap is at the end of the Executive. 
This memory allocation must be taken into account when specifying the 
size of partitions. 
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4.11 PSWD DIRECTIVE 


The password directive specifies a password that may be 
generated system. 


PSWD 


used 


The PSWD directive has the following format. 


= password of up to 6 alphanumeric characters 


NOTE 


None of the software provided with 
RSX-11D uses this password. Passwords 
are assigned to UICs by the’ system 
Manager uSing the PWD command to MCR. 
This directive is provided so that a 
user password facility can be developed 
independently of the RSX-11D  log-on 
procedure. The 6 characters specified 
in a PSWD directive are stored in the 
system communication area at location 
“.MCRPW*. 


in 


the 
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4.12 INS DIRECTIVE 


The install directive installs the system tasks needed to provide the 
target system with the capability to do useful work. The INS 
directive has the following format. 


INS=par-name,file~specifier,file-specifier,...,file-specifier 
par-name = partition name. 


file-specifier = An RSX-11D file containing a task to be 
installed in the named partition. Up to five 
files can be specified in one INS directive. 
The file specifier must not include a device 
mnemonic and must be fewer than 32 (decimal) 
characters. 


Minimally, the disk driver (DK...., DP...., DF...., DB.... Or DM....), 
the terminal handler, F11ACP, and phase 2 of system generation (SGN2) 
must be installed. See the INS directives in the system generation 
command files in Appendix A for examples. Refer to the PAR directive 
(Section 4.6). 


To obtain a list of system tasks that can be installed, print a 
directory of UFD [11,1]. Further discussion can be found in Sections 
5.2.6 and 5.5. 


All tasks installed during phase 1 are assumed to be on the device 
specified in the TARGET directive. It is further assumed that they 
are to be on the target SY when phase 2 executes. 


The following limitations apply to phase 1 installation of tasks and 
Shareable Global Areas (SGAs) 


e No more than 15 tasks can be installed in phase l. 

e No more than 15 tasks and SGAs can be installed into a single 
partition. 

e The system disk handler and System Generation phase-2 can not 


bind to an SGA or have a read-only segment. 
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4.13 SYSBLD DIRECTIVE 


The SYSBLD directive is used to define the file that will be read by 
SGN2 in processing MCR commands. The SYSBLD directive has_ the 
following format. 


SYSBLD=[ufd] filename.ext 
wheres: 


{ufd] is the UFD containing the command file. The 
default is [11,17] 


filename.ext is the filename and extension used to name the 
file to be read. The default is SYSBLD.CMD. 


If the SYSBLD directive is omitted Sysgen Phase 2 will read the file 
[11,17]SYSBLD.CMD. Only one SYSBLD directive is permitted. A device 
specification is not allowed. The file should exist on the system 
disk by the time it is booted to perform phase 2 of Sysgen. 


4.14 PHASE 2 DIRECTIVE (*DELAY) 


The *DELAY directive causes a 1l-second delay in the processing of 
Phase 2 commands. Phase 2 sequentially retrieves and executes MCR 
commands from the file named by the SYSBLD directive, or, if none was 
specified, from [11,17] SYSBLD.CMD. Each command is allowed to finish 
before the next command is executed. 


The *DELAY directive does not have any parameters. 


CHAPTER 5 


ADDITIONAL SYSTEM GENERATION INFORMATION 


Once the system is placed on disk from the distribution medium as 
explained in Chapter 2, system generation can begin. RSX-11D system 
generation proceeds in two phases. 


Phase 1 defines the hardware configuration, specifies system defaults, 
and installs the system tasks required for execution of phase 2. 
System generation directives are used to _ supply the required 
information. 


Phase 2 performs a series of actions requested in the indirect file 
specified by the SYSBLD directive, or, if none was’ specified, 
[11,17] SYSBLD.CMD. Phase 2 information cannot be typed at a terminal. 
Once all the reguests in the SYSBLD file are performed, the 
newly-generated system is operational. 


5.1 EDITING SYSTEM GENERATION FILES 


Several indirect command files for system generation are provided in 


They can be used to define the system to phase 1 instead of typing 
directives in response to phase 1 requests. A SYSBLD file is always 
used to perform phase 2. If the user wishes to tailor the system to a 
particular installation, he can either edit the existing files or 


create new ones. See the RSX-11D Utility Programs Procedures Manual 
for a description of the editor. 


All commands files are stored under UFD [11,17]. Type the following 
command to reguest the editor for modification of existing generation 
files or the creation of new ones. 


MCR>SET /UIC=[11,17] 
MCR>EDI command file 
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5.2 PHASE 1 OF SYSTEM GENERATION 


Phase al system generation directives are divided into’ seven 
categories: 


1. The TARGET directive that defines the target system device. 
2. The PDP11 directive that defines the computer to be used. 


3. The EXEC, SCOM, and PAR, directives that divide the computer 
memory into the Executive, the system communication area, and 
partitions, respectively. 


4. The DEV directives that define the system peripherals. 


5. The DPAR, DUIC, CKPNT, PSWD, and SY directives that supply 
system default information. 


6. The INS directives that install tasks needed for phase 2. 


7. #The SYSBLD directive which defines the file which is to be 
processed by Phase 2. 


Regardless of whether the directives are to be typed in response to 
system generation requests or an indirect file is to be used, each 
category of directives is separated from the preceding category by a 
record containing only a slash (/). The end of input to phase 1 is 
indicated by a record containing two slashes (//). See the examples in 
Appendix A. 


‘To reach the point where the directives are entered, perform the 
appropriate steps as detailed in Chapter 3 through step 8 of Section 
3.1. At this point, the following message is printed on the terminal. 


SYSGEN PHASE1 
SPECIFY TARGET DEVICE AND FILENAME 


5.2.1 Target Specification 


When the message SPECIFY TARGET DEVICE AND FILENAME is printed on the 
console, the user can type the TARGET directive or the name of the 
indirect command file to be used. Alternatively, the user can _ type 
both; see Section 3.1, steps 9 and 196. 


If the TARGET directive is used, it establishes a complete description 
of where the output file of SGN1 is to be created and with what name. 
The following example creates a file named 48KV62.SAV on DKl1 under UFD 
fll, 17}. 


SGN>TARGET=DK1: [11,17] 48KV62.SAV 
As with any other directive, the TARGET directive can be included in 


the command file, in which case the procedure is as described in 
Section 3.1. 
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After entering the TARGET directive, SGNl1 again prompts. The response 
at this point is either a command file name or a slash (/) to cause 
the CPU specification prompt as in the following example. 


SGN>TARGET=DK1: [11,17] 48KV62 
SGN>/ 


ENTER CPU SPECIFICATION 


SGN> 


5.2.2 CPU Specification 


When the message ENTER CPU SPECIFICATION is printed on the _ console, 
the user types the PDP1l1l directive. Enter the PDP11 directive 
followed by a record containing only a slash (/) as in this example. 


SGN>PDP11=49,48K 
SGN>/ 


5.2.3 Memory Allocation 


The memory allocation directives make it possible for the user to 
place the Executive and system common area in memory and to establish 
partitions and shared regions. The allocation of memory is 
accomplished using the following directives: 

e EXEC (optional), 

@ SCOM (required), 

e PAR (required). 
These directives can be entered in any order in response to the 
following request that is printed on the console. The order of the 
PAR directives specifies the order of partitions in memory, unless 
base addresses are specified. 

SPECIFY DIVISION OF MEMORY 


The memory allocation directives must be followed by a _ record 
containing only a slash (/). 


5.2.4 Device Specifications 
Type the DEV directives in response to the following message. 
SPECIFY DEVICES 


When all directives are entered, type a record containing a slash (/). 


5.2.5 System Default Specifications 


Once the device specifications are entered, the system requests’ the 
default directives as follows. 


SPECIFY DEFAULTS 
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Any of the following directives can be typed at this point: 


DPAR, 
DUIC 
CKPNT, 
PSWD, 
SY. 


The directives can be in any order. The last directive must be 
followed by a record containing a slash (/). 


5.2.6 Required Task Installations 


At the completion of phase 1, a target system exists that can operate 
as an independent RSX-11D_ system. It must contain an RSX-11D 
Executive that can either satisfy its intended end-use requirements or 
be capable of expanding itself to do so. Therefore, the final portion 
of phase 1 installs the tasks required to accomplish this end. 


When a task is installed, it is given an entry in the system task 
directory (STD). This entry allows the system to load the task without 
making use of the file system. 


Selection of tasks for installation depends on the following’ two 
factors: 


1. The capabilities defined for the target system, 


2. The procedures to be used in creating the operational target 
system. 


If the target system is to operate as an independent RSX-11D system 
following bootstrap, it must have tasks installed in it that are 
capable of doing the required work. 


While processing the INS directives, phase 1 of system generation 
checks for the names of two system tasks: the disk handler for the 
system disk and phase 2 of system generation. These tasks are 
installed and, upon bootstrap, are running. The device handler is 
either DK...., DP...., DF...., DB...-., DM.... Or DS.... depending on 
the unit assigned SY. Phase 2 of system generation is called SGN2. If 
these tasks are not named in the INS directive, the system is not 
operational when bootstrapped. 


Normally other tasks must be installed in addition to the disk handler 
and SGN2. Typically the following additional tasks are installed: 


Install (INS), 

Mount (MOU), 

File system primitives, 
Terminal handler (TT), 
MCR. 


A critical decision centers on the inclusion of the INS MCR- function. 
Unless INS is installed during phase 1, the target system is unable to 
install tasks. Such systems may not be uncommon; for example, a 
remote data collector involves few tasks, is rigidly defined, and is 
generated to occupy minimum core, thus having no need for INS. 


Since phase 2 of system generation automatically mounts the _ system 


device, the appropriate file primitive tasks must be installed during 
phase 1. Two versions of the directory device file primitives are 
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provided. Both have the task name FI11ACP. One has the filename 
FCP.TSK. It is a small, heavily overlaid version of the task. The 
other is named BIGFCP.TSK and is minimally overlaid. 


If the user has his own file primitives, he should set the default ACP 
name in the DEV directive and install that task during phase l. 


With the minimum number of required tasks installed, the installation 
of any additional tasks can occur during phase 2. The decision to 
install. additional tasks during phase 2 is partly procedural and 
partly due to the 15-task installation limitation of phase l. 


The system prints the following message to request the INS directives. 
SPECIFY INSTALLS 


THE INS directives should be followed by a record containing one 
Slash(/) or if no SYSBLD directive is to be specified then two slashes 


(//) « 


5.2.7 Specification of SYSBLD Command Files 
The system will request the SYSBLD command file by typing 
SPECIFY SYSBLD COMMAND FILE SPECIFICATION 


The name of the appropriate command file should be entered. After the 
SYSBLD directive has been typed enter a record consisting of two 
Slashes (//). 


5.2.8 Pool Requirements of SGN1 


Phase 1 of system generation uses the dynamic pool for storage of 
input data and for communication with the version of install (...INV) 
that it requests. SGNl returns nodes to the pool as soon as it has 
finished with them. If a fatal error occurs, it returns all nodes 
using its own internal accounting system. 


As a result, pool usage is guite dynamic. The important 
consideration, however, is the maximum usage at any time. To compute 
the maximum pool usage consider the phase 1 command input’ while 
referring to Figure 5-1. 


EXECUTION OF SGN1 


TARGET 
PAR 
DEV 
INS 


SYSBLD 


Loop repeats 
once for 
each task 
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NODE USAGE 


1 node = 16 contiguous words. 


This graph does not include MCR buffers or nodes 


and/or GCD 


1 node only if UIC and/or filename is specified 
1 per PAR 


Return task description data 
Request ..-INV 
---INV creates an STD 


used by the file system. 


3 4 5 6 7 8 9 10 


1 per DEV 


l per task and 1 for each partition for which installs 
are specified 


Calculate system mapping 

Create target system image file 
Exec, null task, pool written out 
PUDS created and written out 

3 nodes picked for control of ...INV 
(2 further nodes if SYSBLD specified) 


All tasks installed in target system 
Return 1 ...INV control node 


Return all device information nodes - 1 per DEV 
Write alpha table 

Write STDs 

Return STDs -- 1 per task 


Create ATL entries 
Write partitions 
Return PAR data -- 1 per PAR 


Return STDs and GCDs 

Create bootstrap on virtual block 1 

Write SCOM to memory 

Close files 

Return all outstanding nodes -- 3 if SGNl1 is successful 


““——~ All fatal SGN1 errors enter here 


Figure 5-1 SGNl1 Pool Usage 
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5.3 PHASE 2 OF SYSTEM GENERATION 


Phase 2 of system generation is installed during phase 1. On bootstrap 
from a phase 1 target disk as described in Section 2.3, phase 2 is 
activated and proceeds as follows: 


1. Loads the terminal handler, 
2. Issues a MOUNT command for the system device (SY), 


3. Opens the file SY:[11,17]SYSBLD.CMD, or other user specified 
file and if the open is successful, begins to process’ the 
file and print it on the console. 


The file SYSBLD.CMD is provided in the RSX-11D system. If the user 
wishes to modify it, he should do so before bootstrapping phase 2. 


SYSBLD.CMD can contain the phase 2 directive described in Chapter 3, 
*DELAY, and any MCR request except SAVE or BOOT. 


A task must be installed before it can be used. The task can be 
installed either during phase 2 of system generation or by the INS MCR 
request. If the task refers to a shared region, the region referred 
to must be installed before the task is installed. 


When phase 2 is complete, it prints the following message on the 
console. 


END OF SYSTEM GENERATION PHASE 2 


At this point, perform the steps in Section 3.2 starting with step 4. 
This process properly saves the system for continued use. 


5.4 RSX-11D BOOTSTRAPPING 


The PDP-1l1 family of computers is supplied with a hardware 
bootstrapping program in read only memory. The function of this 
program is to read one block (physical block @) of a specified device 
into main memory starting at real location zero. On successful 
completion of the read, the processor jumps to real location zero with 
memory management disabled and starts to execute the contents. 


Under RSX-11D, block zero of the booted device must contain a program 
to read in the whole operating system and user-defined partitions, 
enable memory management, and start the Executive. 


During the generation and subsequent management of an RSX-11D system, 
the operations related to the bootstrap go through several phases. 
Although these operations are relatively transparent to the user, the 
system manager should be aware of the actions taken and their 
implications. The operations can be divided into the following four 
categories. 

1. Phase 1 of system generation 

2. Phase 2 of system generation 

3. Saving the generated system 


4. Subsequent bootstrapping and saving of a stable system 
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5.4.1 System Generation Phase 1 (SGN1) 


The purpose of the first phase of system generation iS to create a 
file; e.g., RSX.SAV, on a target disk. This file is a bootable 


RSX-11D system image configured for the target hardware; i<e.y. the 
contents of RSX.SAV on completion of phase 1 are independent of the 
hardware configuration on which it was created. The only 


bootstrap-related function performed by SGNl is to include the 
bootstrap at the beginning of the RSX-11D image file. 


Due to differences among mass_ storage device controllers, the 
bootstraps for various devices differ in their control logic. 
Therefore, RSX-11D provides a bootstrap program for each different 
device supported as a system device. The bootstrap programs are named 
using the convention xxxxBOOT.TSK. xxxx is the commonly-used name _ for 
the device. At present, bootstraps are supplied for RK@5, RK@#6, RF1l, 
RP@3, RP@4, RS@4 disk devices. 


The RK#@3 uses RK#5BOOT, the RS#3 uses RS#4BOOT, the RP#@2 uses RPY3BOOT 
and the RP@5 and RP@6 use RP#4BOOT. 


Using the SY directive and the related device specification, SGN] 
determines which bootstrap task is to be written into the beginning of 
the memory image file that it is creating. 


Before it writes this task into the image file, however, SGN1 must 
insert the following information into the program. 


1. The amount of memory to be filled (upper limit 124K words). 
2. The disk address of the RSX.SAV file. 


3. The real base address of the Executive (to load kernel APR 
when memory management is enabled). 


4. The external page address of the disk controller as specified 
by the corresponding DEV directive. 


5. The kernel virtual address of the power recovery routine 
within the Executive. This routine is used to start the 
Executive as well as to recover from a power failure. 


The first four items are available to SGNl. The last (power recovery 
routine address) is obtained by building the appropriate bootstrap 
task with the Executive symbol table, EXEC.STB. SGN1, therefore, 
inserts items one through five above into the bootstrap task before 
writing it to the RSX.SAV file. 


To insert the required information, SGNl must have access to. the 
symbol table of the bootstrap task. Conseguently, SGN1 also reads 
xXxXxxBOOT.STB to determine the bootstrap program’s data locations. 
Since the bootstrap is linked with the EXEC.STB, SGNI1 is able to 
locate all other symbols for the target Executive from the bootstrap 
task symbol file. 


During phase 1 of system generation, the user has the option of 
defining base addresses for the Executive, the system communication 
area, and partitions. If base addresses are not specified, SGN1 
performs a memory allocation and places the Executive on the next 32 
word boundary after the bootstrap program. SGN1 determines the length 
of each bootstrap from the corresponding .STB file. 
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If the user specifies the base address, he must take care to leave 
sufficient space for the bootstrap program. The user can determine 
the bootstrap size by obtaining a task builder listing of the 
appropriate xxxxBOOT.STB. The following command is used. 


TKB>,LP:=[11,17]xxxxBOOT.STB 


The value of .BO.ND (end bootstrap) rounded up to the next 32 word 
(198 octal) boundary provides the lowest real address at which the 
Executive can be placed. 


Whenever the executive is rebuilt using the [11,15]TKB15.CMD command 
file the bootstraps must also be rebuilt using the command file 
[11,17]BOOTSBLD.CMD. This is because system generation phase 1 
obtains all executive symbols from the apporpriate xxxxBOOT.STB symbol 
table file. 


It is important to note that unlike earlier versions of RSX-11D, 
version 6.2 and subsequent versions do not write block @ of the target 
system device. Rather, it places the bootstrap task at the beginning 
of the memory image file created by phase l. 


5.4.2 System Generation Phase 2 (SGN2) 


Some of the functions necessary for a complete system generation must 
be performed on the target hardware configuration (e.g., creation of 
the checkpoint file). Others are more conveniently performed under the 
target software configuration (e.g., installation of a large number of 
tasks). Therefore, phase 1 of system generation creates a _runnable 
RSX-11D system with SGN2 installed and loaded into its partition. 
When the Executive starts, it activates SGN2. 


SGN2 makes no modifications to the bootstrap program either in memory 
or on disk. The only bootstrap-related aspect of SGN2 is the initial 
bootstrapping of the output file from SGNl1. This bootstrapping causes 
the system disk handler to be activated on the first ATL scan and SGN2 
to be activated on the second ATL scan. 


There are two methods of booting the output of SGNI1: 
1. By using the MCR BOOT function, 


2. By using a combination of the MCR BOOT function and the 
hardware bootstrap (ROM). 


Whichever method is used, the output of SGN1 always must be booted 
from the device that was specified as SY during phase l. 


When the first method is used, all devices except the bootstrap device 
must be dismounted to ensure that all activity within the system is 
stopped. Then the MCR BOOT function is requested and given the file 
specifier of the image file to be booted. The BOOT task reads the 
first block of the image file into memory starting at real zero and 
begins to execute it. This process simulates the ROM bootstrap. BOOT 
does not require block zero of the device to have any special content. 
It uses the first virtual block of the image file specified. 


With the second method, BOOT is used to create a bootstrap block @ on 
the device. Then the device can be booted with the appropriate 
hardware ROM. BOOT accepts the switch /WB following the file 
specifier for the RSX-11D image file to be booted. If this switch is 
present, the first block of the file is copied to block @ of the same 
volume. This procedure does not perform a system reload, but does 
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make the volume hardware bootable. 


The inclusion of the BOOT MCR function allows the complete generation 
and testing of a new RSX-11D system without changing the target device 
substantially. The only modification to the target device is the 
creation of a new memory image file and installation of tasks into 
that system. Note that task headers are impure, i.e., they are 
modified when a task is installed. Therefore, even though it is 
possible to reboot a disk on which a new RSX-11D image file has been 
created, care must be taken with such tasks as INS, MOU, and FI11ACP, 
if they are not fixed, because their headers will reflect the new 
system. This problem can be circumvented by making separate copies of 
such tasks before running SGNl. 


It is possible to have more than one complete running system on the 
same disk. However very great care is needed. All systems must have 
the same number of partitions and devices. Devices which are common 
to one or more systems must be in the same relative position in the 
list of DEV directives. This is because the task headers contain 
pointers to system data structures. If these precautions are not 
observed a system crash will almost certainly occur whenever any of 
the systems is booted. 


For further information about BOOT, refer to the RSX-11D User’s Guide. 


5.4.3 Saving a Generated System 


When SGN2 runs’ successfully, all the facilities of the generated 
RSX-11D system are available. Once the user is satisfied that the 
system does perform as intended, it is necessary to dismount all 
devices and save the updated memory-resident system on the bootstrap 
device. If extensive testing of the new system is intended, it is 
advisable to save the system first. 


The purpose of the SAVE MCR function is to rewrite the file that was 
originally booted. SAVE uses the bootstrap program that is 
permanently resident in low memory to perform this’ function. This 
approach insures the following: 


1. Only as much memory as specified during SGNI1 is written, 


2. Memory is saved at the disk address (i.e., in the image file) 
from which it is to be booted. 


NOTE 


The booting of a previous save image should only be done if 
the system environment is known to be the same as it was when 
the save image was created. Serious errors can occur if, for 
example, tasks which were installed at the time the image was 
created have been moved or deleted. 


3. The device on which the file is saved is independent of any 
redirection of SY or other devices. That is, the save takes 
place on the device from which it was booted. 
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Because the output of SAVE is an exact replica of memory, the RSX-11D 
image file appears as a system with the SAVE task running. In order 
for SAVE to exit, it makes several modifications to the bootstrap in 
low memory after copying it into its own buffer to perform the disk 
write and before performing the actual save. These modifications are 
as follows. 


1. Store the content of user APRQ. 


2. Store the re-entry address in SAVE which is relative to user 
APR@. 


3. Modify an internal branch within the bootstrap so that a 
seguence of instructions to return to SAVE in user mode is 
executed after memory management is enabled. 


At this point, two versions of the bootstrap program exist in memory: 
the original within SAVE and a modified version beginning at real 
location @. 


SAVE now changes the I/O function code of its version from a read to a 
write, inhibits task switching and interrupts (processor priority 7), 
and executes its version of the bootstrap. Upon completion of the 
save to disk, SAVE executes the same code that it executes when 
rebooting the saved memory image, as described in the next section. 


Before a save of the system can be attempted, the system must be 
quiescent. The SAV function ensures that no activity is taking place 
by searching the system data base for any of the following conditions: 


1. Mounted devices, 


2. A user logged onto any terminal except the one from which SAV 
was initiated, 


3. Tasks with I/O in progress, 
4. Tasks being loaded or checkpointed, 


5. Shareable global areas being loaded or, in the case of 
read/write common areas, being written to disk, 


6. Tasks loaded or fixed beyond the end of the system image 
file; that is, the SAV file (possible only on extended 
memory PDP-11/7@). 


7. Shareable global areas, including the read-only portion of a 
multiuser task, loaded beyond the end of the save _ file 
(possible only on extended memory PDP-11/79). 


8. Tasks with send/receive data queued. 


9. Tasks or SGAs_ installed from devices other than the system 
disk. 


If any of these conditions is detected, SAV prints an appropriate 
message and exits. 


Before writing the system to disk, SAV translates the absolute disk 
addresses if task image files, shareable global areas and _ the 
checkpoint file into the corresponding file-id. Since this is 
independent of absolute disk addresses these files may be relocated on 
the disk, for example by the DSC utility. When the system is booted 
the file-ids are translated back into absolute disk address using the 
file structure on the disk, as described in the next section. 


Sed 
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5.4.4 Subsequent Rebooting of a Saved Image 


Regardless of which method is used to boot a saved RSX-11D system, the 
bootstrap program that performs the read originally came from virtual 
block 1 of the file being booted. This bootstrap overlays itself with 
the beginning of the file it is reading. Since the only differences 
between bootstraps is in data, the instructions continue to execute. 


On completion of the read of memory, which is performed in 1K 
increments, the overlay copy of the bootstrap executes -a seguence of 
instructions that returns to SAVE in user mode with task switching and 
interrupts inhibited. SAVE then restores all volatile registers, 
restores the power recovery vector which was used to direct the 
bootstrap to SAVE, and performs a number of other functions not 
related to the bootstrap. Upon completion, task switching and 
interrupts are enabled and the Executive is started by simulating a 
power fail AST. Finally, SAVE prints the RSX-11D sign-on message and 
exits. 


One of the other functions performed by SAVE is to check the existence 
of the system clock. Since RSX-11D can use either a KWI1-L or a 
KW11-P clock, SAVE first checks for the clock for which the system was 
generated. If this test fails, SAVE attempts to start the other type 
of clock. Therefore, it is possible to boot an RSX-11D system _ that 
waS generated and saved on a configuration with a different type of 
clock. As described in the next section, SAVE performs a number of 
memory size checks and adjustments before it exits. This checking can 
be inhibited by applying the /NOXT switch to the SAVE command. 


As mentioned in section 5.4.3, when the system is booted SAV has _ to 
translate the file-id stored in the saved image for each installed 
task and shareable global area and the checkpoint file into an 
absolute disk address. Normally this process is not apparent to the 
user, except that it may take up to several minutes. If hardware 
errors are detected while reading the disk or if task files have been 
deleted SAV recovers the system as far as possible. 


Unless the offending block or file is one of a small number of 
critical ones the system will still be runnable. The error messages 
which may be produced are described in Appendix A of the RSX-11D 
Users Guide. 


5.5 MEMORY ALLOCATION AND USAGE 


This section provides additional information about the way in which 
RSX-11D allocates and uses memory. It also provides some guidelines | 
for the choice of partitions and their sizes. 


The initial memory size is specified to phase 1 of system generation 
by means of the PDP1l directive. This guantity establishes the size 
of the save file and, consequently, the amount of system memory that 
can be saved and booted. 


The maximum length of the save file is 124K words. If the hardware is 
a PDP-11/70, the system can be generated for up to 192@K words. Phase 
1 of system generation accounts for the fact that the hardware is a 
PDP-11/70 with more than 124K. Regardless of the hardware, however, 
the save file cannot exceed 124K words. 


The size of the system components (bootstrap, Executive, SCOM 
communication region and SCOM subroutines) is determined by phase 1 of 
system generation from the bootstrap symbol table file on the target 
disk. The STB file contains all global symbols of the Executive and 
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the bootstrap. If the user intends to specify base addresses for all 
partitions, this STB file should be examined by obtaining a task build 
map with only the STB file as input. The following symbols’ provide 
the necessary sizes. 


-BO.ND Bootstrap size 
-SG.EX Size of Executive 
-SG.BE minus’ .SG.BC Total size of SCOM communication region 


and subroutines excluding the node pool 


Once these sizes are obtained, base addresses can be assigned without 
wasting memory. 


If the user does not specify base addresses, phase 1 performs all size 
calculations and positions all components optimally to avoid wasting 
memory. Memory is allocated from location zero upward. The amount of 
memory available for partitions is the initial specification in the 
PDPll directive minus the total lengths of the bootstrap, Executive, 
and SCOM. The length of SCOM is user-defined and consists of the node 
pool, communications region, and subroutines. 


When base addresses are not specified, the partitions are allocated by 
phase 1 in the order that they are specified to phase 1. The size of 
all partitions except one must be specified. One partition can be 
given a partition size of asterisk (*). Phase 1 computes’ that 
partition’s size from the memory remaining after memory for all other 
partitions is allocated. The asterisk has no effect on the base 
address of the partition. It only affects its size and, consequently, 
the base address of all succeeding partitions. 


The asterisk can be used with the specification of base addresses. 
The resulting partition size is the difference between the base 
address of this partition and the next. 


During phase 1, the bootstrap, Executive, SCOM, system disk handler, 
and phase 2 of system generation are written into the save file on the 
target disk. Since the save file has a maximum length of 124K words, 
phase 1 ensures that all are positioned below the 124K boundary when 
generating a PDP-11/79 system with more memory. RSX-11D requires a 
minimum of two partitions: one for the system disk handler and one 
for the phase 2 task. Depending upon the application for which the 
user has chosen RSX-11D, these two partitions may be sufficient. Then 
the system consists of a user-controlled system disk partition and a 
system-controlled general (GEN) partition using all the remaining 
memory. 


Partitions are used to provide areas of memory that can quarantee an 
acceptable response time to requests for tasks. However, the 
existence of too many infrequently-used partitions can result in the 
wasting of memory for long periods of time. Partition design involves 
trade-offs among the following desirable goals: 


e Fast response to task initialization, 

e Maintaining a high level of memory usage, 

e Minimizing memory fragmentation in multitask partitions, 

® Minimizing the possibility of frequent checkpointing of low 


priority tasks that are compute bound in a partition where 
high priority tasks must run, 
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e Maintaining a fast response for all terminals, 
e Maintaining high throughput for all file activity. 


The choice of relative partition sizes depends on the application 
environment. In particular, different partition sizes are chosen in a 
system with many terminals than in one with a predominantly process 
control environment. 


After an RSX-11D system generation, the system is saved in the image 
file as described in Section 5.4.3. SAVE is the task that is resident 
in a saved system and is the task that initiates a system restart. 


SAVE has the capability of adapting the system size to match that of 
the machine on which the system is- run. If the machine is a 
PDP-11/78, SAVE interrogates a register that defines the amount of 
memory available. On all other machines SAVE determines the system 
size by actually testing memory in 1K increments, starting at 32K. 
SAVE attempts to expand or truncate one or more partitions to reflect 
the available memory. Automatic expansion and truncation can be 
inhibited by using the /NOXT switch in the SAVE command. 


Memory expansion is the simpler process. In this case, the size of 
the last partition in memory, that is, the highest addressed 
partition, is increased by the value of the expansion. If the highest 
partition is a system-controlled partition, the last hole pointer in 
that partition is updated to reflect the new size of that hole. 


To make effective use of the expansion facility, the last partition 
should be a system-controlled partition. If the expanded partition is 
a user-controlled partition, only one task can be active in it at a 
time regardless of the expanded size. 


If the memory size has decreased, SAVE attempts to truncate one or 
more partitions starting from the highest end of memory. It is 
impossible for this process to be successful in the following 
circumstances: 


1. Any occupied partition reduces to zero size, 


2. <Any truncation occurs in an occupied user-controlled 
partition, 


3. The truncation of an occupied system-controlled partition is 
so extensive that a previously allocated area of memory no 
longer exists. 


In summary, any amount of truncation can occur in the unoccupied part 
of a system-controlled partition and in an unoccupied user-controlled 
partition, including truncation of the whole partition. 


CHAPTER 6 


TAILORING THE SYSTEM 


Several system components can be modified to suit the particular needs 
of an installation. The tasks which can be modified, and the ways of 
modifying them, vary from release to release and are described in the 
Release Notes. This chapter provides an outline to the subject. 


6.1 EXECUTIVE CHANGES 


In addition to the tailoring implicit in the system generation 
process, it is possible to build the executive task EXEC.TSK in 
different ways: 


1. A crash dump module may be included, to dump all of the 
memory to a scratch device automatically if it crashes. The 
dump may be analyzed using the Core Dump Analyzer (CDA), 
which is documented in Chapter 6 of the RSX-11D System 
Managers Guide. 


2. Some executive modules may be replaced by null modules if 
their function is not required. 


These changes are described in the file [11,15]TKB15.CMD, which 
appears as an appendix to the RSX-11D System Managers Guide. 


6.2 UTILITY PROGRAMS 


Many utility programs use the /INC facility of INSTALL to increase the 
available space for symbol tables, buffer areas, etc. In general 
giving a larger value for the /INC option will make the utility run 
faster or provide more space for data structures. There is a list in 
the Release Notes of the tasks affected. 


APPENDIX A 


EXAMPLES OF SYSTEM GENERATION FILES 


A.1 TERMINAL AND INTERFACE CONFIGURATION FILE, [311,114] CONFIG.MAC 


See Sections 2.4.1, 2.4.3 


»SBTTL TERMINAL AND INTERFACE CONFIGURATION FILE 

se 

> THIS FILE CONTAINS THE MACRO CALLS TO DEFINE THE TERMINALS ANO 
) INTERFACES PRESENT IN THIS SYSTEM, 

je 


} 
3 COPYRIGHT (CC) 1976 
9 DIGITAL EQUIPMENT CORPORATION, MAYNARD; MASS 


= 


AUTHOR 
DATE 


JOHN HARPER 
26eJUL=76 


Frrst DEFINE EACH INTERFACE PRESENT IN THE SYSTEM, IN THE FORME 
INTF NUMBER, TYPE, ADDRESS, VECTOR[,EXTRA] 


NUMBER INTERFACE NUMBER, STARTING AT ZERO, INTERFACE ZERO MUST 
ALWAYS BE THE CONSOLE DLii, 
TYPE IS THE INTERFACE TYPE (E.G, 'DL', 'DHI) 
ADDRESS IS THE EXTERNAL PAGE ADDRESS OF THE INTERFACE 
VECTOR IS THE INTERRUPT VECTOR ADDRESS 
EXTRA IF PRESENT CONTAINS INTERFACE DEPENDENT INFORMATIONS 
DL «© NONwZERO IF OLUIE 
DH * INTERFACE NUMBER OF ASSOCIATED DHil, IF ANY, OTHERWISE 
BLANK, THE OM MUST PRECEDE THE DH, AND MUST NOT 
NOT BE INTERFACE ZERO. 
DC « 1 FOR OC11AA, 2 FOR DCI1AB, ETC, @ FOR DC114xX 


= Te te we Ge Ge TP TE TH SO TO TO TWO US Te TE WW Te Te GS TO 


INTE @,DL,177568, 060 
INTE 1,DH,160020,34@ 
INTF 2,04,170500,310 
INTF 3,0H, 160040, 352,2 
INTF 4,0L,375610,328,1 
INTF 5,03, 160010,330 
INTE 6,0.,176590,300 


EXAMPLE OF SYSTEM GENERATION FILES 


A.2 SYSTEM GENERATION PHASE 1 


See Chapter 3.1 


ye 
Now DEFINE EACH TERMINAL IN THE SYSTEM, USING: 
TERM NUMBER, INTNUM, SUBLINE, TYPE, <SPEED>, <DIALUP>, <<CHAR>> 


’ 
; 
| 
’ 
; NUMBER Is THE TERMINAL NUMBER STARTING AT ZERO 

3 INTNUM IS THE NUMBER OF THE INTERFACE TO WHICH IT IS CONNECTED 

; SUBLINE IS THE SUBLINE ON THE INTERFACE (BLANK FOR NON@MULTIPLEXOR 
; INTERFACES, E,G, DLi1) 

; TyPE 1S THE TERMINAL TYPE, QUT OF: AS33, KS33, AS35, L32S, 

} L3@P, LA36, V1O5, VT5O, VT52, VT55, VT61, 

§ SPEED (MUST BE IN BRACKETS JF PRESENT) JS EITHER ONE VALUE FOR 

; SINGLE*SPEED TERMINALS OR <KEYBOARD SPEED, PRINTER SPEED> 
’ FOR SPLITeSPEED TERMINALS, 

, DIALUP IS EITHER BLANK FOR NON@DIALUP LINES OR '<DJALUP>! FOR 

’ DIALUP LINES 

; <<CHAR>> JS A LIST OF CHARACTERISTICS (5RACKETTED PAIRS THEMSELVES 
; ENCLOSED IN BRACKETS) WHICH ARE NOT STANDARD FOR THIS 

} TERMINAL TYPE, FOR A LIST OF THESE CHARACTERISTICS. SEE 

’ DEVICE HANDLER REF MANUAL CHAPTER 2 OR THE FILE 

; (314,114) TBLS,MAC 

| 


TERM BH, 9, eL A36 

TERM 1,1,0,VT5 

TERM 2riel VTS 

TERM S,ie2,VT50 

TERM 4,1,3,VT52 

TERM 5,1,4,V750 

TERM 6,1/5,L50S 

TERM 7,1,6,L38S 

TERM 19r14+7+L308 

TERM 11,3,0,4833,,<sDI ALUP> 


TERM 1253,1,4833,,<DIALUP> 
TERM 13,3,2,A833,,<DIALUP> 
TERM 1463,3,4S33,,<DJALUP> 
TERM 1543,4,AS33,,<O01 ALUP> 
TERM 16635eA4S33,-<DI ALUP> 
TERM 17,3,6,V158,302 

TERM 200307 7VTO5 

TERM 21,4,,LA36 

TERM 2205+8+L38S 

TERM 237551 ,L 436 

TERM 2405+4/VT5O 

TERM 25,5,5,VT50 

TERM 26-6,,USRO,<158,1200>,,<<SCP,1>,<SMP,1>> 


EXAMPLE OF SYSTEM GENERATION FILES 


A.3 SYSTEM GENERATION PHASE 2 


See the beginning of Chapter 3 and Chapters 4.13, 
[11,17]SYSBLD.CMD. 


) 

’ ttit,i%27)RK O@5L48k , CMD 

’ 

; COMMAND FILE FOR GENERATING A 48K RSXIID SYSTEM ON AN 11742 
} WITH A LINE CLOCK, WITH Dkees AS SYSTEM DISK 

’ 

PDP11840, 48K 

/ 

$ComMe, 382,96 

PARSSYOISK,,37.U 


PARsMCR, 141,58 
PARSGENs¢ teS 


/ 

DEVaDK2, RKO5 
DEVatK1sRK@5 
DEVaDpG,RPOSB 
DEVspBe, RPa4 
DEVsDM2,RKG6 
DEVatT@,CONSOL 
DEVaLP@,LPiiB 
DEVapTa,OT14 
DEVeoTi,OTI13 
DEVaemTO, UIC 
DEVamMm®, TUL6 
DEVaMQ 

OEVasp 

/ 


DPARSGEN 
SY"DK2 


4 

INSasyDISK, (11,11) DK 

INSMGEN, [1,1] SYSRES/LI/ACCERO 

INSMGEN? (1-11 TTLIBA/LI 

INSHGEN, [L,4] TYILIBB/LY 

INSBGEN, (31,1) TT 

INSBGENes [11,172 SGN2, (19,2 MOU, C1L,1) INS/UTCE 01,1), 031,10) FCP 
A} 


EXAMPLE OF SYSTEM GENERATION FILES 


{41%,!7)SYSBLO,CMHMD 


Seava wae nweeeaen®R2evea se sFaeaavrueaat*ea 


INPUT FILE TO SYSGEN PHASE 2, ANY MCR FUNCTION IS ALLOWED 
EXCEPT SAV AND BOO. CARE MUST BE TAKEN THAT ANY TASK 
REQUIRED BY SG2 HAS BEEN INSTALLED BEFORE SG2 TRIES TO 
USE IT, 

NOTEs 
SYSTEM GENERATION PHASE2 ("SGN2") IS INSTALLED AND 
LOADED GY SYSTEM GENERATION PHASE { ("SGNi") SUCH THAT 
BOOTING THE NEW SYSTEM DISK RESULTS IN THE RUNNING OF 
SGN2. 
SGN2 PERFORMS THE FOLLOWING FUNCTYONS AUTOMATICALLYS 
(1), CHECK THERE 1S SUFFICIENT MEMORY 
(2), CHECK THAT SYSTEM DISK HANOLER IS ACTIVE 
(3), PICK THE SPECIFIED NODES FOR TERMINAL ISR 
(4), REQUEST THE TERMINAL HANDLER ("TTyeoe”) 
(5), CHECK THAT TT,,., BECOMES ACTIVE 
(6), MOUNT THE SYSTEM DISK 
(7), OPEN FOR READ (THIS) FILE, SY¥3 (11,17) SYSBLD,CMD 
SGN2 ASSUMES THAT THE FILESe11 ANCILIARY CONTROL PROCESSOR 
("FUG ACP”) HAS BEEN INSTALLED AS WELL AS TTyeeee MOUNT (%,,,MOU") 
INSTALL THE TASK TERMINATION NOTIFIER (€",TKTN,") 
NS c¢1lisl) TKTN 
INSTALL MCR, THE COMBINED MCR FUNCTION TASK (%,,,MFT") 
AND THE MCR ERROR TASK 
FOR SYSTEMS WHICH RUN THE LARGE TERMINAL HANOLER (TT) INSTEAD 


OF TYG@i, MCR SHOULD BE INSTALLED USING? 
INS (C11,1) TIMCR/UICs (1,1) 


=e @e we Te we SS US P41 te TS Ge TE Ge TS De TH Ge TR HO SO GE we te TE Te TE GS Ge TE UE Ge Te VS Te te TE GE TE Ge GE He Be SE MS Te WE 


INS tlie) MCR/UICS (1,1) 
filet] MFT 
INS (11,1) CRERR 


~ 
2 
i? ] 


NOTE? 


| ALL THE ABOVE FUNCTIONS MUST BE PERFORMED AS SHOWN, ANY 
MODIFICATIONS SHOULD BE MADE BELOw, 


=e te te Ge Gs Ge GS TS YS 


THE TASK ACCOUNTING UTILITY TASKS 


=e 


(41,1) ACCLOG 
tii, l] ACCRPT 
(11,1) ACCOFF 
INS (146!) ACCAQT 


mere ee 
222 
Aan 


NS 


NS 


2. 


} 
INS 


=e 4S Ge GS we TW 


EXAMPLE OF SYSTEM GENERATION FILES 


MCR FUNCTION TO QUTPUT THE ACTIVE TASK LIST 


til,ijacr 
THE BAD BLOCK DETECTION UTILITY ",,,BAD" 
[1121] BAD 
NOW THE BATCH SYSTEM 
tit,i) Bar 
ti1,1] BPR 


MCR FUNCTION FOR BOOTING SYSTEMS AND WRITING BOOTSTRAP 
BLOCKS 


tii!) 800 

THE LOGGING OFF MCR FUNCTION 
(11,1) BYE 

THE CRASK DUMP ANALYSER 
tiiei}CDda 

THE FILE COMPARE UTILITY 
tit,3] CMP 


THE GLOBAL CROSS REFERENCE TASK C"CRF,.,.") REQUESTED BY 
eee TKB WHENEVER /CR IS SPECIFIED ON A MAP 
OR eeeMAC WHENEVER /CR IS SPECIFIED ON A LISTING 


THERE ARE TWO VERSIONS OF CROSS REFERENCE ew 

1) OVERLAYED INSTALLED BY INS (11,1) CRF 

2) UNOVERLAYED THIS HAS TO BE BUILT USING COMMAND 
FILES SUPPLIED ON THE AUXILIARY MEDIA 
UNDER UFD (11,23), wHEN BUILT, IT IS 
INSTALLED BY INS [14,1)UNOVRCRF 


BOTH VERSIONS HAVE TASK NAME "CRF,,," 


THE EXECUTION TIME OF THE BOTH VERSIONS MAY BE 

DECREASED BY ALLOCATING MORE CORE SPACE AT INSTALL 

TIME USING THE /INCSNNNNN SWITCH, NNNNN MAY BE ANY VALUE 
FROM @ TG 1988@ APPROx FOR (11,1)CRF (DEF AULTa@) 
FROM @ TO 2800@ APPROX FOR (11,1) UNOVRCRFE (DEFAULT 81600@) 
HIGHER VALUES GIVE FASTER EXECUTION 


THE MEMORY YSAGE DISPLAY (VT@5 ONLY) TASK ",.,DEM" 
(11,1) DEMO 
THE AVAILABLE DISK HANDLERS ARE AS FOLLOWS) 


FOR RKef{1 (RKO3,RKB5) DEVICES: 
tii.1) DK 
FOR RKeii wITK OVERLAPPED SEEKS ON 
MULTIPLE NRIVES: 
INS (11,1) 0KOVL 
FOR RFw=1t MULTI PLATTER FIXED HEAD DISKS: 
INS [11,1] DF 
FOR RP#11C (RPB?,RPBS) DEVICES: 


EXAMPLE OF SYSTEM GENERATION FILES 


InS (11,1) DP 
FOR RP@4 MASSBUS DISKS: 
INS (11,1}06 
FOR RSO3, RS@4 MASSBUS FIXED HEAD DISKS?! 
INS [i!,1)DS 
FOR RK611 (RK@6) DISKS 
INS (11,1) 0m 
AND THE DIAGNOSTIC EQUIVALENTS! 
INS (11,27) DKD 
INS (11,271)DPD 
INS (11,27) DFO 
INS ¢(11,27)080 
INS ¢11-271)080 
INS (11,27)0M0 
ONE OF THESE WILL BE THE SYSTEM DISK HANDLER ALREADY INSTALLED 
AND LOADED BY SYSGEN PHASE |. IT IS INAPPROPRIATE TO 
ASSUME HERE WHICH IS THE SYSTEM DISK OR WHICH ADDITIONAL DISK 
DEVICES A USER WISHES TO USE, THEREFORE SELECTION OF FURTHER 
OISK HANDLERS FOR INSTALLATION IS LEFT TO THE USER, 
ANY OF THE ABOVE MAY BE INSTALLED SIMPLY BY EDITING THIS FILE TO 
DELETING THE "3" AND TAB PRECEDING THE FILE SPECIFICATION, 
THE DISMOUNT YOLUME MCR FUNCTION 
NS 31,1} 0M0 
THE FILE DUMP MCR UTILITY 
NS ¢i4,3) 0MP 
THE FLOPPY DISK HANDLER 
INS (41,1) DX 
THE DECTAPE HANDLER 
ALTERNATE 3 
. THE DIAGNOSTIC HANDLERS 
INS (11227)DTDO 
NS (34,3) 0T 
LINE TEXT EDITOR (LETTER) ",,,E0I" 


ADDITIONAL: 


Run wr Vweeag 


FOR THE SLIPR EDITOR? 
INS [41,1] SLP 


NS {(Li,1J EDI/PRIs60 


THE HARDWARE ERROR LOGGING TASK USED IN CONJUNCTION 
WITH ERROR LOGGING HANDLERS, 


me we We FG SO Be GE GE GS GS TS SS UW fF TO DF TO ee eS Se WS Ow WE Uwe fe Ge UG fd Ss eS es SSO Ge TS SS te Ge 6S Se Ge SS Ge Ge 6G Ge Oe Ge Oe Gs Se Ge 6G Te Ge 0S TS SO Ge Ge we Se we Ge Ge TO 


z z z z z z 2 z z z z 2 z 
@ @ @ Lf) @ © @ @ @ @ @ i?) @ 


~a Ue TO WO US TO TE TO TO Us UH ES FG BS BE ES OE TF TS WS Hg UE BE UE Fg TO TS TS O-E TS WO TE OG UE GD UE Og TR OH GD ed TO TO UP 6-6 TO GS Be FG OD TE UD FE TE TE TO OG OP ts WE GSE Te UE Pd TO 
z 
(7. 


EXAMPLE OF SYSTEM GENERATION FILES 


til, 1 ERRLOG 
THE FILE INTERCHANGE UTILITY (TO AND FROM DOS, RT#11, RSTS SYSTEMS) 
(ii, 1) FLX/PRI855 
FILESe11 MESSAGE OUTPUTTING TASK 
til, t)FLIMSG 
THE LOG ON MCR FUNCTION 
(4452) NEL 
FILES*11 VOLUME INITIALIZATION MCR FUNCTION 
tude tj Ine 
THE LIBRARIAN (RELOCATABLE OJECTS AND RANDOM ACCESS MACROS) 
tiie3)Ler 
LINE PRINTER HANDLER 
til, SLP 
THE LOGICAL UNIT INFORMATION MCR FUNCTION 
tiie1) LUN 
THE MESSAGE OUTPUT (PSEUDO) HANDLER MOsee, 
t41,1) MO 
THE MEMORY EXAMINATION AND PATCH UTILITY 
tii,1) OPE 
THE OPERATOR'S SPOOLER CONTROL MCR FUNCTION 
tit,i]0PR 
THE FILESe1{ PERIPHERAL AND FILE INTERCHANGE FUNCTION 
tiie) PIP/PRISS5 
THE POOL USAGE DISPLAYING UTILITY 
th1,1) POOL 
THE ONLINE PRESERVE UTILITY ",..PRE" 
(11/1) PRE 
THE VERSIONS OF THE MACROw1i ASSEMBLER ARE AS FOLLOWS: 
FOR SMALL, HEAVILY OVERLAYED TASK} 
INS (11,1) MAC 
FOR THE LARGE, UNOVERLAYED ASSEMBLER TASKS, 
UNUCECURD Tie pines BUrcO Rleee ON THE AUXILIARY MEDIA 
(11,20) MACBLD,CMD BYILDS [11/1] MAC. TSK, THE OVERLAYED VERSION, 
{11,1@8) PURMACBLD.CMD BUILDS (11,4]PURMAC, TSK, THE UNOVERLAVED 


; 
} 
; 
J 
3 
U 
} 
J 
} 
} 
} 
} 
} 
U 
} 
rf 


NS 


i 

9INS (ile 1) MAC/INC #15000 
r] 

FINS [Cile lL] PURMAC/INC a 4000 
3 

PINS [14¢1)2 PURMAC 


we tg TO Ge Ge Ve GE ee DO TO iG TS GO GE GCE De GE 6 Te Oe te 4 TE we US FG SO Ge Ue i SS TE GE f-G TO GS GF f-§ TO GF GS ws TO 


EXAMPLE OF SYSTEM GENERATION FILES 


VERSION, 
ALL HAVE THE TASK NAME ",,.MaAC" 
THE EXECUTION TIME OF THESE ASSEMBLERS May 
BE DECREASED CONSIDERABLY WHEN THE NUMBER OF SYMBOLS IS LARGE 
BY ALLOCATING THE ASSEMBLER MORE CORE RESIDENT wORK SPACE, 
THIS MAY BE ACHIEVED BY INSTALLING THE TASK USING THE 
*"/INCSNNNNN"® SWITCH ON THE COMMAND TO INSTALL, THIS IS 
RECOMMENDED IF IT IS NECESSARY TO RE*BUILD THE TERMINAL HANDLER 
TASK (TTeeesnde THE VALUE FOR 'NNNNN' MAY BE 
8 TO 15800 (APPROX) FOR (11,1) MAC (DEFAULT#8192) 
@ TQ {2000 (APPROX) FOR (11,1) PURMAC (DEF AULT#120@02) 
FOR THE SMALL, OVERLAYED TASK? 
tit, 2) Mac 
FOR A LARGER, FASTER, OVERLAYED TASK! 
FOR THE FAST, LARGE, UNOVERLAYED TASK; 


FOR THE FASTEST, LARGE» UNOVERLAYED TAaSKk3 


THE MCR FUNCTION FOR INSERTING PASSWORDS INTO SPECIFIED UFD'S 
ON THE SYSTEM DISK, 


tite) Pwo 

THE MCR FUNCTION TO QUEUE A FILE FOR OUTPUT 
rii,1) QUE 

THE LOGICAL UNIT REASSIGNMENT FUNCTION 
rii,t) REA 

THE DEVICE REDIRECTION MCR FUNCTION 
tiie1] RED 

THE MCR FUNCTION FOR REMOVING TASKS AND 8GaA'S 
t1i,1) REM 

THE TASK RUNNING MCR FUNCTION 
(14,2) RUN 

THE SYSTEM SAVING AND RESTARTING MCR FUNCTION 
(11,1) SAV 

THE SYSTEM PARAMETER SETTING MCR FUNCTION 
t11,1) SET 

THE SPOOLER TASK "SPR..." 
11.1) SPR 


THE DESPOOLER TASK "SPR2,," SET FOR 1 DEVICE. INCREMENTS OF 
462 WORDS SUPPORT ONE MORE DEVICE 


tii,1}] SFR2/INC #8460 


3 
} 
INS 
i] 
U 
’ 
INS 
' 
’ 
} 
INS 


NS 


we 6 To TSO De Of Te TO TE 4 TO we Te +4 TO Te WS 6 TO SO TS TS TS OF eG TO CE US WH be OS Ge Te tO He Ge GS FG tO WO Ge Te ee US 06S Ge we 6S MO Ye Ge GS SS US te OD 


EXAMPLE OF SYSTEM GENERATION FILES 


THE SYSTEM INFORMATION MCR FUNCTION 
fiis1) SYS 
THE ON@LINE TERMINAL CHARACTERISTIC CHANGING FUNCTION 
tilt,t) TER 
THE TIME SETTING AND ENQUIRING FUNCTION 
tiiei) TIM 
THE LINKER (TASK BUILDER) 
THERE ARE TWO VERSIONS OF TASK BUILDER oe 
1) OVERLAYED INSTALLED BY INS [Ctyrt) TKB 
2) UNOVERLAYED THIS HAS TO BE BUILT USING COMMAND 
FILES SUPPLIED ON THE AUXILIARY MEDIA 
UNDER UFO (41,11), wHEN BUILT, IT IS 
INSTALLED BY INS [i£4-1) UNOVRTKB 
BOTH VERSIONS HAVE TASK NAME ",,,TKB" , 
THE EXECUTION TIME OF THE OVERLAYED VERSION MAY BE 
DECREASED BY ALLOCATING IT MORE CORE SPACE AT INSTALL 
TIME USING THE /INC#NNNNN SWITCH, NNNNN MAY BE ANY 
VALUE FROM @ TO 12000 APPROX, HIGHER VALUES GIVE 
FASTER EXECUTION, 
fi1,1}] TKB 
THE MAGTAPE HANDLER, 


ALTERNATES 


“MMeeee” FOR TJUL6 MASSBUS CONTROLLER; 
fii,1]) TU16 
AND THE DIAGNOSTIC VERSION? 
INS (11-27) TUL6D 


"MT ecee" FOR YMeii TULG DEVICES: 
tit,1) Ture 


AND ITS DIAGNOSTIC VERSION: 
INS (11/27) TU19D 


THE USER FILE DIRECTORY CREATION MCR FUNCTION 
tii,i)UFD 

THE DEVICE HANDLER UNLOADING FUNCTION 
tite) UNL 

THE FILESw11 SYSTEM VERIFICATION MCR FUNCTION 
tii,tlvFy 

THE TERMINALS IN USE DISPLAY UTILITY ",,,WHO" 
tii.) WHO 

THE FILE PATCH UTILITY ",,,ZaP" 
t11,1) ZAP 


BUFFERIN 
ACCESS F 


ED gyasP 


NOTE 1.8 


NOTE 2.3 
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EXAMPLE OF SYSTEM GENERATION FILES 


THE SPOOLER USES A PSEUDO DEVICE SP; FOR QUEUING AND 


G, THIS DEVICE MUST BE REDIRECTED TO SOME RANDOM 
ILESe41 DEVICE WITH A UFD (1.4) /PROs(RWED,RWED,RWED,RWED) 


ASSUME HERE THAT IT IS THE SYSTEM DEVICE, 


AFTER SGN2 HAS PROCESSED ALL THE COMMANDS IN THIS FILE 
IT WILL THEN PROCEED TO ALLOCATE THE CHECKPOINT FILE (IF 
AND aS) SPECIFIED DURING PHASE 1, 


THE DEVICE TO WHICH CHECKPOINTED TASKS ARE TO BE WRITTEN 
MUST HAVE ITS HANDLER RESTOENTs MUST BE INITIALIZED aS A 
FILES=ii VOLUME AND MUST BE MOUNTED FOR SGN2 TO CREATE THE 
CHECKPOINT FILE. 

THEREFORE IF If I$ A VOLUME OTHER THAN THE SYSTEM DEVICE 
INSERT THE APPROPRIATE INSTALL» LOAD AND MOUNT COMMANDS IN 
THIS FILE. 

DIRECTIVE, 


AFTER SGN2 COMPLETES, THE USER SHOULD LOG ON TO THE SYSTEM, 
PERFORM THOSE FUNCTIONS DEEMED DESIRABLE AND THEN SAVE THE SYSTEM, 


TYPICAL POST SGN2 FUNCTIONS ARE3 

LOA MQ 3 LOAD MO HANDLER 

LOA LP LOAD THE LINE PRINTER HANDLER 

RED LPaCL LINE PRINTER IS CONSOLE LISTING DEVICE 
REA »eeeTKB 8 DS REASSIGN THE WORKFILE LUNS OF 

REA CRFeeoe 7 DS TKB, MAC AND CRF TO 

REA seeMAC 8 DS A FIXED HEAD DISK, 

TIM HHSMM3SS DD@eMMMeYY ENTER TIME AND DATE 

RUN ACCLOG RUN THE ACCOUNT LOGGER 


ALTERNATIVELY, THIS FILE MAY BE EDITED TO 
INCORPORATE THESE COMMANDS, 


=e we TS GO De GS De 


A-10 


APPENDIX B 


DEVICE CHARACTERISTICS WORDS 


THIS MODULE CONTAINS! 


1 e= CODE FOR DOVSCH, 


eSBITL 


OVSCH == THE DEVICE CHARACTERISTICS MACRO 


MACRO TO GENERATE AN ENTRY IN THE DEVICE CHARACTERISTICS 


TABLE, 


MACRO FORMAT? 


DEVCGH 
WHERE 3 


DE VCH 
eRADSO 


eWORD 
eWORD 
ewWORD 
ewORD 
ellIF 
el IF 
ellIF 
ol IF 
el IF 
olIF 
ol IF 
olIF 


NAME, ACS» AC2,AC3,AC4, ACP, BNAM,VSIZH,VSIZL,VECT»PRI-CSR 


NAME 


Aci 
AC2 
AC3 
Ac4 


CFOR DEFINITION 


ACP 
BNAM 


VSIZK 


VSIZL 
VECT 
PRI 
CSR 


DEVICE NAME STORED AS TWO RADS2 


WORDS, 
PUD CHARACTERISTICS WORD 1 (DEV, INDEP,) 
4 "2 (DEV, DEPEN,) 
" n 3 (DEV, DEPEN,) 
" n 4 (TXFR, SIZE) 


OF THE ABOVE, SEE EXECUTIVE AND APPROPRIATE 
DEVICE HANOLER) 


DEFAULT ACP FOR THIS DEVICE 

FOUR ASCIT CHARACTERS WHICH 
IDENTIFY THE BOOTSTRAP 
PROGRAM, 
(2 ZERO WORDS FOR NON#BOOTABLE 
DEVICES) 

HIGH ORDER PART OF VOLUME SIZE 
FOR DIRECTORY DEVICES, 
(ZERO FOR OTHERS) 

LOW ORDER VOL, SIZE 

DEFAULT VECTOR ADORESS 

DEFUALT PRIORITY 

DEFUALT CONTROL/STATUS REGISTER ADDRESS 


ANAME,AC1,AC2,AC3,AC4,ACP,BNAM, VSIZHeVSIZL,VECT,PRI,CSR, 22 


/ANAME/ 


NB <ACP> 

B <ACP> 

NB «<BNAM> 
B <BNAM> 
NB <VSIZH> 
B <VSIZHe 
NB <VSIZL> 
B «<VSIZL> 


eRADSB /ACP/ 


WORD @ 
eASCII /BNAM/ 
eBLKW 2 
«WORD VSIZH 
e WORD a 
» WORD VSTZL 
eWORD ".) 


DCHST: 


elIfF 
ellF 
elIF 
ollF 
ellF 
el IF 


SB ,9Z 
eENDM 


DEVICE CHARACTERISTICS WORDS 


NB <VECT> eWORD  VECT 
B <VECT> eWORD @ 

NB <PRI> eWORD = PRI 

B <PRID WORD @ 

NB <CSR> WORD CSR 

B <CS§R> eHORD A 


BLENGTH OF CHARACTERISTICS TABLE 


eSBTTL OVSCH += STANDARD SUPPORTED DEVICE CHARACTERISTICS 


DEFINE THE DEVICE CHARACTERISTICS TABLE 


DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVGH 
DEVCK 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
OEVGH 
DEVCGH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCK 


oIF DF IAS 


eENDC 


DCHENS 


DEVCH 
DEVCH 


DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 


PTR, 40,0,0,1800, 54 557054,177550 

PTP, 40,878, 10B8p 645 9740451775858 
RK93,142010,21060,1014,512,,F11,RK95,,4800,,220,5,1774900 
LP114,3,9,8,8Bep0454208,4,177514 
LP13B,3,8,8,13200¢0¢5200,4,177514 

LPLIWU, SsBe Berl 32ann gop 2OB,4,177514 

LPLIWL eo Sake Qe l3eeorerns 2O00,4,177514 

LPLYINUG 35Be Op 8Ou peop 208, 4,177514 

LPLINL 30458, 8l e540 97 hOB, 4,177514 

LSILWU se Se 2rDelS2eqnnree 200744177514 

LSLIWL oe Sp SeBol3S2eno nee 208,4,1778146 
LSLINU,342,0,8B e544 97288,4,177514 
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ERROR MESSAGES 


During system generation, errors detected cause a message to be 
printed on the console. Phase 1 messages are preceded by a SGNI1; 
phase 2 messages are preceded by SGN2. System generation produces 
three types of error messages. 


1. Diagnostic messages -- These messages are informative and do 
not result in termination of system generation. The user 
should not force termination if a diagnostic message is 
printed. Diagnostic messages are prefixed as follows. 


SGn -- *DIAG* 


2. Diagnostic message dependent on console input -- These 
message are nonfatal if console intervention is possible. If 
input is from an indirect file, the error is declared fatal. 


3. Fatal error messages -- These errors are not recoverable. 
System generation terminates the current attempt to build the 
system. Fatal error messages are prefixed as follows. 


SGn -- *FATAL* 


Error messages in this appendix are divided into one section for phase 
1 messages and another for phase 2 messages. Within each’ section, 
messages are presented in alphabetic order. 


For terminal handler configuration error messages see Section 2.4.5. 


1. PHASE 1 ERROR MESSAGES 


In the following section, the number associated with each message is 
the internal message number within SGN1. 


CANNOT REQUEST ...INV 40 


Failure of the REQUEST directive or corruption of the 
communication data sent by SGN] to ...INV (the special 
version of INSTALL) has occurred. If the latter is 
true, remove and reinstall ...INV and then try 
rerunning phase l. 


DUPLICATE NAME 3 
A device name or partition name has appeared more’ than 
once. 

ERROR IN READING TASK IMAGE 27 


An attempt to read a task has failed. The failure is 
probably due to hardware errors on the device. 
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ERROR IN STD TABLE CONSTRUCTION 
SGN1 has failed internally. 
ERROR ON COMMAND INPUT 


A hardware failure has occurred on attempting to read 
command input 


EXECUTIVE CROSSES 124K BOUNDARY 


The base address assigned to the Executive is such that 
it does not reside completely within the save file on 
PDP-11/76. The Executive must be below the 124K 
boundary to fit in the save file. Reassign the base 
addresses. 


FAILED TO PICK VIRTUAL SCOM NODE 


No more nodes available from node pool of system being 
generated. Specify a larger SCOM size so that more 
nodes are available. 


FAILED TO REMAP GCD NODE ADDRESS 


Indicates an internal error within SGN1 while 
converting the GCD nodes of the present system to the 
addresses of the new system. 


-FP OPTION ILLEGAL FOR 11/35 AND 11/498 
The FP field of the PDP11 directive specifies the 
presence of the FP1l1 floating point processor. This 
option is not available on a PDP-11/35 OR 11/49. 


To perform floating point calculations on a PDP-11/35 
or PDP-11/48, the floating point instruction set (FIS) 


must be present. The presence of the floating point 
instruction set is not specified during system 
generation. 


I-O ERROR ON FILE filename 
I/O error has occurred on reading or writing the named 
file. For example, the volume may be write-locked 
during a write operation. 

ILLEGAL CHECKPOINT DEVICE 


The checkpoint device was not defined by a 
DEV=directive. 


ILLEGAL ERROR -- SEVERITY number 
SGNl1 has failed internally. 
ILLEGAL MACHINE TYPE 


The only CPU types supported by RSX-11D are 


ILLEGAL MEMORY SIZE OR BASE ADDRESS 


A system or partition size specification is larger than 
that allowed on the specified CPU; that is, greater 
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than 124K for a PDP-11/34,35,480,45,50,55 or greater 
than 192@K on a PDP-11/7@. Alternatively, a base 
address specified is beyond the usable memory of a 
system with the specified CPU type. 

ILLEGAL MULTI-PARAMETER SETS 


Muliple parameter sets have occurred in a directive 
that permits only one parameter set. 


ILLEGAL “SY” INPUT 


This message can be caused by any one of the following 
conditions. 


Undefined device (no DEV command associated with it) 
Invalid mnemonic 
Device for which no bootstrap program exists (see 
Section 5.4) 

IMPROPER "@" FILE SPECIFICATION 
File syntax specification incorrect. 


INSUFFICIENT PARAMETERS 


All the parameters required by the directive have not 
been submitted. 


INVALID ACP TASKNAME 
The specified name of the file primitve tasks for this 
device was not nnnACP; i.e., the last three characters 
are erroneous. 


INVALID DEVICE TYPE <type> 


Device type not recognizable. The device type is not 
defined internally in system generation. 


INVALID KEYWORD IDENTIFIER 
Keyword in a directive cannot be recognized.: 
INVALID PARTITION NAME 


An attempt has been made to install a task in a 
nonexistent partition. 


INVALID PARTITION PRIORITY 


The priority of a T partition must be between 2 and 2086 
(decimal). 


INVALID PARTITION TYPE 


Only user-controller (U), system-controlled (S), and 
time scheduled (T) partitions are acceptable. 


INVALID SYSBLD DIRECTIVE 


SYSBLD directive file specification contained device 
name Or was more than 31 characters in length. 
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INVALID TARGET DEVICE SPECIFICATION 


A syntax error was made in specifying the target device 
and filename. 


INVALID TASK HEADER 


Bad data was found in the header of a task INV has 
installed. Possibly a task has become corrupted. 
Start phase 1 again. 


MARK TIME OR WAIT FOR DIRECTIVE FAILURE 


SGN1 failed to issue one of these directives 
successfully. 


MORE THAN 15 INSTALLS TO A PARTITION 
No more than 15 tasks and/or Shareable Global Areas can 
be installed in a partition during phase 1. This 
message shows this limit has been exceeded. 


MULTIPLE PARTITIONS WITH * SIZE SPECIFICATION NOT PERMITTED 


Only one partition can use the wild card memory size 
specification. Specify a partition size for all 
partitions except one and retry. 


MULTIPLE SYSBLD DIRECTIVES NOT PERMITTED 


Only one SYSBLD directive is permitted. Delete any 
additional SYSBLD directives and retry. 


MULTIPLE TARGET DIRECTIVES NOT PERMITTED 


Only one target device and filename specification can 
be used. Delete any extra target specifications and 
retry. 


NO DYNAMIC STORAGE AVAILABLE 


No more nodes are available. Indicates nested 
generations may be required. Thus, the user must 
generate successively larger systems until he reaches 
his target system. Alternatively, some running on or 
installed tasks should be removed; then try again. 
NON-EXISTENT "@" FILE SPECIFIED 
The indirect file specified cannot be found. 
NO SPACE FOR POOL 
SCOM size insufficient to provide for any pool. 
NO TELETYPE HANDLER (TT....) INSTALLED 


After all the installs for phase 1 were processed, SGN1 
found that no task with the name TT.... was installed. 
Insert the directive to install TT.... in the phase l 
command file. This message is a warning; the system 
is operable. 


NO TELETYPE ZERO DEFINED CI, CO, AND CL NOT REDIRECTED 
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LT 


TT®@ was not asSign. CI, CO, and CL have no assignments 
and should be redirected when the target system is 
initiated. 


OPEN FAILURE ON FILE filename 


File cannot be opened. The failure has occurred in 
attempting to open EXEC.TSK, one of the bootstrap .TSK 
or .STB files, or the system image output file. 
Usually either the file does not exist, or no room 
exists on the disk to create the output file. 


OPTION LINE SYNTAX ERROR 

A syntax error exists in a directive line. 
OUTPUT I-O ERROR ON FILE filename 

An I/O error has occurred when writing the save file. 
OVERLAP IN REAL ADDRESS SPACE 


The base specifications and size specifications result 
in a space allocation conflict. 


POSITIONING ERROR ON FILE filename 


This message indicates an internal system failure. 
Contact local software support. 


REAL MEMORY SIZE EXCEEDED 


After summing memory requests, those requests are found 
to exceed the amount specified by the PDPll directive. 


SCOM CROSSES 124K BOUNDARY 


The base addresses and sizes specified for the system 
are such that SCOM cannot be contained completely 
within the save file on a PDP-11/79. SCOM must be below 
the 124K boundary to fit in the save file. Reassign 
the base addresses and/or adjust the sizes of the 
components. 


SGN2 CROSSES 124K BOUNDARY 


Because SGl writes the system generation phase 2 task 
out to the save file, which has a maximum length of 
124K, SGN2 must reside below the 124K boundary in a 
PDP-11/79. Adjust the partitions or install SGN2 in 
another partition. 


STD/GCD ENTRY NOT FOUND FOR A TASK/SGA AFTER INSTALL 


INSTALL has failed to create an STD or GCD entry. 
INSTALL may issue a message in addition to the one 
issued by SGNi. Aiternatively, INV may not have run_ to 
completion. 


SY DISK HANDLER CROSSES 124K BOUNDARY 
Since SGl writes the system disk handler into the save 
file, which has a maximum length of 124K, the system 


disk handler must reside below that boundary on a 
PDP-11/78. Adjust the partitions or install the disk 
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handler in another partition. 
SYMBOL NOT FOUND symbol 
A symbol needed by SGN1 cannot be found in the 


appropriate bootstrap .STB file. The file either has 
not been built or has been built incorrectly. 


SYSGEN PHASE 2 NOT INSTALLED 


After all phase 1 installs were processed, SGNI1 
determined that SGN2 was not installed. 


SYSTEM DISK HANDLER NOT INSTALLED 
No task with the name xy.... was installed. xy is the 
device specified in the SY directive, which was valid. 
See Section 4.2.5. 

SYSTEM DISK NOT DEFINED, “SY° NOT REDIRECTED 
SY has not been defined explicitly. Therefore, SGN] is 
attempting, by default, to redirect SY to DK@. 
However, no such device has been defined by a DEV 
directive; SY cannot be redirected. 

TASK ..-INV NOT IN SYSTEM 


SGNl1 requires the task ...INV to operate but the task 
cannot be found. 


TOO MANY PARAMETERS 


More than the allowable number of parameters have 
appeared in the directive. 


VIRTUAL ADDRESS SPACE OF SCOM OUT OF RANGE 
The size specified for SCOM makes the virtual starting 


address less than 1@@@9@0: Administrator must reduce 
the size of SCOM. The maximum size of SCOM is 12K. 
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2. PHASE 2 ERROR MESSAGES 

ALL MEMORY SPECIFIED DOES NOT RESPOND 
SGN2 attempts to initialize hole pointers in partitions 
whose base addresses are beyond 124K on a PDP-11/7@. 
Memory access at one of these base addresses produced a 
memory system timeout. 

ASSIGN LUN ERROR 
SGN2 cannot assign a LUN to SY. 

CHECKPOINT FILE ALLOCATION ERROR 
There is not sufficient contiguous space on the disk to 
allocate the checkpoint file, the device has not been 
mounted, or its handler is not loaded. 

ERROR ON LOGGING DEVICE 
Could not successfully log. 

ILLEGAL FUNCTION FOR NON PRIVILEGED TERMINAL 
The user must be privileged to run phase 2 of system 
generation. In fact, phase 2 should only be run 


automatically by performing the phase 1 procedures. 


IO ERROR 


An 1/0 error has occurred probably due to hardware 
failure during creation of the checkpoint file. 


MARK TIME ERROR 
SGN2 has attempted a MARK TIME and the request failed. 
OPEN ERROR ON SYSBLD.CMD 
[11,17] SYSBLD.CMD could not be opened. 
OPTION LINE SYNTAX ERROR 
A syntax error exists in an SGN2 directive. 
READ ERROR ON COMMAND FILE 
Command file cannot be read. This is probably due to 
hardware errors. 


REQUEST ERROR 


SGN2 has attempted to REQUEST a task and the request 
failed for a reason other than not being installed. 


TASK NOT INSTALLED 
The task ...MFT, which performs some of the MCR 
functions, is not installed. It may be possible to 
perform the installation after SGN2 completes. 


UNABLE TO FIND ATL FOR SYSTEM DISK HANDLER 


SGN2 searches the active task list expecting to find an 
entry for the system disk. No entry is found which 
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suggests that the system disk handler has’ terminated 
abnormally. Progress beyond this point is impossible. 


UNABLE TO FIND ATL FOR TERMINAL HANDLER (TT....) 
SGN2 searches the active task list for an entry for the 
task TT...., but did not find one. It is possible for 
phase 2 to complete, but no errors can be reported and 
no communication can be established with the system 
until a terminal handler is resident. 

WAITFOR ERROR 


A WAITFOR request has failed. 
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